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