Re: Enable linknamespace testing for libdl and libcrypt

[Florian Weimer <fweimer at redhat dot com>]

On 11/16/2016 11:45 PM, Joseph Myers wrote:
> On Wed, 16 Nov 2016, Florian Weimer wrote:
>
> > On 11/16/2016 08:06 PM, Joseph Myers wrote:
> > > +linknamespace-libs-XPG3 = $(linknamespace-libs-isoc) \
> > > +			  $(common-objpfx)crypt/libcrypt.a
> >
> > Does the linknamespace test perform a full link, and fails if it encounters
> > undefined symbols?
>
> No, it has its own emulation of linker logic, and ignores failure to find
> a definition of a symbol (for example, libgcc symbols - it doesn't look
> for libgcc.a / libgcc_eh.a, so it won't detect namespace issues there).
> (If an undefined symbol breaks namespace rules, that will still result in
> a test failure unless whitelisted in linknamespace.pl, whether or not a
> definition of that symbol was found.)

Understood.  Then the linknamespace test fails thusly:

[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOWHASH_Begin
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOWHASH_Destroy
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOWHASH_End
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOWHASH_NewContext
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOWHASH_Update
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOW_Init
[initial] crypt -> [libcrypt.a(crypt-entry.o)] __md5_crypt -> 
[libcrypt.a(md5-crypt.o)] NSSLOW_Shutdown

This is, of course, completely correct and expected.  I don't know what 
to do about it.  XFAIL it?

I'm trying to get rid of NSS-based crypt downstream, but it's going to 
take a while (it's already optional in Fedora).

Florian