200537 - security/nss/cmd/shlibsign breaks building Mozilla/1.4a (worked until 1.3)

Status: RESOLVED DUPLICATE of bug 200179

(NSS :: Build, defect)

Description

[Nicolas Pioch]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314

Trying to build Mozilla/1.4a on Solaris 8 with GCC 3.2.2
exactly like I've been doing with all previous releases successfully
doesn't work anymore.


Reproducible: Always

Steps to Reproduce:
Building 1.4a according to the instructions at
ftp://depot.mcom.com/pub/pioch/mozilla-1.4a/README

Actual Results:  
...
gmake[5]: Leaving directory
`/train/tmp/1.4a/mozilla/security/nss/cmd/shlibsign/mangle'
Thu Apr  3 21:55:14 MEST 2003
SunOS5.8_OPT.OBJ/shlibsign -v -i /train/tmp/1.4a/mozilla/dist/lib/libsoftokn3.so
ld.so.1: SunOS5.8_OPT.OBJ/shlibsign: fatal: libgcc_s.so.1: open failed: No such
file or directory
Killed
gmake[4]: *** [/train/tmp/1.4a/mozilla/dist/lib/libsoftokn3.chk] Error 137
gmake[4]: Leaving directory `/train/tmp/1.4a/mozilla/security/nss/cmd/shlibsign'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/train/tmp/1.4a/mozilla/security/manager'
gmake[2]: *** [tier_95] Error 2
gmake[2]: Leaving directory `/train/tmp/1.4a/mozilla'
gmake[1]: *** [default] Error 2
gmake[1]: Leaving directory `/train/tmp/1.4a/mozilla'
gmake: *** [build] Error 2


Expected Results:  
It should build!

The reason is breaks is that my LD_LIBRARY_PATH has /usr/local/lib
and other stuff in it, but the LD_LIBRARY_PATH gets wiped out apparently
by the script:
  mozilla/security/nss/cmd/shlibsign/sign.sh

which includes:
    LD_LIBRARY_PATH=${1}/lib
    export LD_LIBRARY_PATH

If I change the above line to:
    LD_LIBRARY_PATH="${1}/lib:$LD_LIBRARY_PATH"

then the shlibsign binary (C++ binary dynamically linked against libgcc_s.so.1)
should be able to run.

This is a solaris-only workaround, since LD_LIBRARY_PATH is the variable
used for locating shared libs on Solaris -- other operating systems
may need the same tweaking for the other variables mentionned in this script:
LIBPATH, SHLIB_PATH, DYLD_LIBRARY_PATH, LIBRARY_PATH

On the other hand, there may be security implications I'm not aware of
in leaving the previous paths in LD_LIBRARY_PATH (although if that's only
done during Mozilla compilation, one would have to alter the environment
used to build Mozilla, instead of the end-user machine).

An alternative solution (which I haven't investigated) might be to statically
link the shlibsign binary so that LD_LIBRARY_PATH isn't needed anymore.


Blocker: build buster

Comment 1

[Nicolas Pioch]

Attachment: patch to workaround runtime linker issue on shlibsign

After this change:

SunOS5.8_OPT.OBJ/shlibsign -v -i
/train/tmp/1.4a/mozilla/dist/lib/libsoftokn3.so
Generating DSA Key Pair....done
Library File: ../../security/nss/lib/softoken/SunOS5.8_OPT.OBJ/libsoftokn3.so
347940 bytes
Check File: ../../security/nss/lib/softoken/SunOS5.8_OPT.OBJ/libsoftokn3.chk
Link: libsoftokn3.chk
  hash: 20 bytes
    38 b9 88 6e ac 9a 46 41 78 0f
    62 e4 8c 49 53 73 80 f7 aa 7a
  signature: 40 bytes
    1f 6d fc 42 4c 67 d6 9c 6e 53
    f4 33 b6 e2 5a b2 cb 5d 28 cd
    b3 55 8c 0e a9 72 e5 5b 10 25
    ba 70 81 a3 b6 a1 00 5c 04 2a
SunOS5.8_OPT.OBJ/shlibsign -v -i
/train/tmp/1.4a/mozilla/dist/lib/libfreebl_pure32_3.so
Generating DSA Key Pair....
...

Comment 2

[Wan-Teh Chang]

Thank you for the bug report and patch.  This is a known
bug and will be fixed in Mozilla 1.4 beta.

*** This bug has been marked as a duplicate of 200179 ***