Enable linknamespace testing for libdl and libcrypt

Florian Weimer fweimer@redhat.com
Thu Nov 17 14:23:00 GMT 2016


On 11/17/2016 03:17 PM, Joseph Myers wrote:
> On Thu, 17 Nov 2016, Florian Weimer wrote:
>
>> 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?
>
> Assuming there are no implementation-namespace exports of those functions
> that libcrypt could use instead, that indicates whitelisting in
> linknamespace.pl with a comment referencing a bug filed for nss-crypt
> namespace issues.

Well, this is only relevant if we actually had a libfreebl.a which 
defines the functions above.  I don't think such a thing exists.  Fedora 
and downstreams don't have it, and neither does Debian jessie.

So it's really a “does it make a sound?”-type question.

Florian



More information about the Libc-alpha mailing list