1405268 - shlibsign fails on Solaris due missing htole64 symbol

Status: RESOLVED DUPLICATE of bug 1420060

(NSS :: Libraries, defect, P3)

Description

[Petr Sumbera]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170921064520

Steps to reproduce:

 0:01.46 /usr/bin/gmake -C . -j2 -s -w install
 0:01.48 gmake: Entering directory '/scratch/firefox/obj-x86_64-pc-solaris2.11'
 0:01.62 gmake[1]: Entering directory '/scratch/firefox/obj-x86_64-pc-solaris2.11/browser/installer'
 0:24.75 Executing /scratch/firefox/obj-x86_64-pc-solaris2.11/dist/bin/shlibsign 	
 0:24.79 C_Initialize failed: 0x00000030, CKR_DEVICE_ERROR
 0:24.79 NSPR error code: -5977: Failure to load dynamic library
 0:24.79 Initiailzing softoken failed: 0x00000030, CKR_DEVICE_ERROR
 0:24.79 NSPR error code: -5977: Failure to load dynamic library
 0:24.79 moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB

It turned out that dlopen() fails and dlerrror() returns:
ld.so.1: shlibsign: relocation error: file /scratch/firefox/obj-x86_64-pc-solaris2.11/security/nss/lib/ssl/ssl_ssl3/libfreebl3.so: symbol htole64: referenced symbol not found

The issue is that htole64 is not defined on Solaris and security/nss/lib/freebl/verified/kremlib.h needs to define it for Solaris.

Comment 1

[Petr Sumbera]

Attachment: Bug1405268.patch

Comment 2

[Franziskus Kiefer [:franziskus]]

Comment on attachment 8914707 [details] [diff] [review]
Bug1405268.patch

Review of attachment 8914707 [details] [diff] [review]:
-----------------------------------------------------------------

This file is auto-generated and shouldn't be modified manually. I take this upstream in [1].

[1] https://github.com/FStarLang/kremlin/pull/61

Comment 3

[Benjamin Beurdouche (do not use this account)]

This should be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1419173
Can you please confirm ? Thanks

Comment 4

[Petr Sumbera]

Actually I just realized that there was an issue in my fix. I'm looking into it (bug 1419009).

Comment 5

[Petr Sumbera]

The issue was that I used variants with 'IN' like: LE_IN64. These are expecting pointer not the value. They are working on unaligned memory (e.g. network data stream). Instead I should use just LE_64.

Comment 6

[Benjamin Beurdouche (do not use this account)]

This should now be solved by
https://hg.mozilla.org/projects/nss/rev/d5433562dee489df800d97c8afb72d3b6971cb9f

Comment 7

[Franziskus Kiefer [:franziskus]]

Petr, can you confirm that his is fixed? Note that it didn't land in Firefox yet but only in NSS.

Comment 8

[Petr Sumbera]

I can confirm it's now fixed (it's now even in FF sources).