91224 - NSS build fails when using GNU ld on solaris

Status: RESOLVED FIXED

(NSS :: Build, defect, P1)

Description

[Joseph]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; SunOS 5.8 sun4u)
BuildID:    None

It looks like whatever is generating mozilla/security/nss/lib/freebl/Makefile is
putting in gronky options to ld.
I just updated to the latest versions of autoconf and automake to try and
overcome this; it hasn't worked yet.

Maybe it's detecting and using Sol8's /usr/ccs/bin/ld instead of the GNU
/usr/local/bin/ld [binutils] that is ahead of it in my PATH.

Up until that point, nothing had complained about bad flags/options.


Reproducible: Always
Steps to Reproduce:
1. Get the latest CVS source
2. Configure it with crypto
3. make

Expected Results:  built.  ;)

I marked this as trivial, since the user only needs to un-install the GNU
binutils, or not configure with --enable-crypto

However, I'd *personally* like it if the configuration script for that part were
more intelligent. :)

Comment 1

[cls]

What are the exact error messages that you are seeing?

Comment 2

[Joseph]

Hitting reply; hopefully, this works.
[It didn't; I had to reply via the web interface.  Dang.]

Unfortunately, I've deleted the file that had the STDERR and STDOUT
  of the make process.  However, the first and foremost problem that
  I had was that ld didn't recognize the -B option.  After removing
  the comma between -B and symbolic, a different error was generated
  and the map was output to either STDERR or STDOUT (instead of mapfile.solaris,
  as the makefile had it.  I had also foolishly not figured out that 
  GNU ld didn't accept the various -z foo options, and that it wanted
  -Map mapfile.solaris instead.)  I say 'a different error', since
  a) I don't remember exactly which error it was, and since b) I
  retried it with GNU ld and the flags it was being passed were still
  wrong.
Checking against the Solaris ld manpage, it looks like the Makefile
  was configured for /usr/ccs/bin/ld, instead of /usr/local/bin/ld
  [GNU ld], which was actually run, since it was first in my PATH.
  All the options it was being passed were on the Solaris ld manpage;
  whereas few of them are on the GNU ld manpage.
Basically, it looks to me like the configure script is saying to itself, "Aha!
  Solaris!  I'll use /usr/ccs/bin/ld!" before even checking to make 
  sure that I'm going to be using Solaris's ld when it comes time to
  build.
Given that it compiles great under Debian/Linux with exactly those same
  options, I'd almost be willing to bet that it's not that the configure
  script doesn't understand GNU ld options.  ;)
I'm compiling it again right now, without binutils installed.  If you want,
  I can check back in when it (hopefully) compiles.  :)

                              -Joseph

Comment 3

[cls]

The NSS makefiles obviously assume that you're using Sun's ld and not GNU ld
which is wrong or should, at minimum, be clearly stated.  NSS is built mostly
independent of what Mozilla's toplevel configure script finds.  Reassigning to
the NSS product.

Comment 4

[Wan-Teh Chang]

Attachment: Proposed patch. Set LD to the full pathname of Sun's ld.

Comment 5

[Wan-Teh Chang]

Chris is right.  Mozilla's configure script does not affect
the makefiles of NSS and NSS does assume you are using Sun's
ld.

My proposed patch to mozilla/security/coreconf/SunOS5.mk
sets LD to the hardcoded full pathname of Sun's ld to ensure
that the assumption is true.

Comment 6

[Wan-Teh Chang]

*** Bug 102124 has been marked as a duplicate of this bug. ***

Comment 7

[Wan-Teh Chang]

Attachment: Proposed patch. Always use Sun's ld and invoke it with its full pathname.

Comment 8

[Wan-Teh Chang]

I would appreciate a code review of my patch
(attachment 56046 [details] [diff] [review]).

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

The patch looks to me like it should always work.

The code being replaced/removed was put there in response to an older
bug report complaining that the build didn't work with GNU's loader.
I wonder if there are any reasons why someone would want to use gnu's 
loader rather than Solaris's.  Might it have something to do with the
version of libc (or other default libs) linked in?

Comment 10

[Wan-Teh Chang]

Nelson Bolyard wrote:
> I wonder if there are any reasons why someone would want to use gnu's 
> loader rather than Solaris's.  Might it have something to do with the
> version of libc (or other default libs) linked in?

It seems that most people did not realize that they were using gnu'd
loader, and they did not notice any difference because their makefiles
did not use any advanced linker options like freebl's Makefile does.

To control the version of libc or other default libs linked in, one
would have to use the compiler (gcc) as the front-end to the loader.

Comment 11

[Wan-Teh Chang]

Hmm... this reminds me -- it is necessary to use gcc to
link so that it pulls in the right version of libc or
default libs.  This is because we are using the -z defs
linker option, which requires all symbols be resolved.

Let me test my patch with gcc on Solaris.

Comment 12

[Wan-Teh Chang]

Comment on attachment 56046 [details] [diff] [review]
Proposed patch.  Always use Sun's ld and invoke it with its full pathname.

This patch is flawed.  There is
a reason we have to use gcc to link
the freebl shared libraries.

Comment 13

[Wan-Teh Chang]

I did some research into this issue.  I don't have
a solution that will always work, but here are some
solutions suggested by the "PROBLEMS" file in the
xemacs distribution.

1. We can invoke gcc with the -B/usr/ccs/bin/ flag.
   This tells gcc to search for programs it needs
   (as, ld, etc.) in the /usr/ccs/bin directory
   first.

   In the recent gcc releases (2.95 or newer), gcc
   can be configured to invoke as or ld with a
   hardcoded pathname. (See solution 2 below.) I
   believe that the -B/prefix/ flag has no effect
   on gcc configured this way.

2. You can build gcc with these configure flags:
   --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as

3. You can uninstall GNU ld.

I have a fourth solution, which I don't like.

4. Add a new coreconf option, USE_GNU_LD, which
   is set to 1 if the Mozilla client is configured
   with the --with-gnu-ld flag.  Then, the NSS
   makefile will test for the USE_GNU_LD variable
   and pass the right linker flags to gcc.

My proposal is to check in solution 1 and recommend
solutions 2 and 3 to people building NSS.  I will
attach a patch that implements solution 1.

Comment 14

[Wan-Teh Chang]

Attachment: Proposed patch. Use the -B/usr/ccs/bin/ gcc flag.

Comment 15

[hacker formerly known as [e-mail]]

*** Bug 111593 has been marked as a duplicate of this bug. ***

Comment 16

[Wan-Teh Chang]

Defer to NSS 3.4.

Comment 17

[Stefan Kost]

Attachment: makefile changes to make it compile with gnu ld

Comment 18

[Wan-Teh Chang]

Comment on attachment 59829 [details]
makefile changes to make it compile with gnu ld

Thanks for providing us with your solution.
Could you find out what is the gcc flag
equivalent to -M?  It is probably
--version-script, which is what we use
on Linux.

I would also appreciate it if you could
test my patch.	My patch works around the
problem by trying to use the native Solaris ld.

Comment 19

[Wan-Teh Chang]

I am lowering the priority to P3 and moving the target to
NSS 4.0 since no one who encountered this problem has
tested my proposed patch (attachment 56265 [details] [diff] [review]).

Comment 20

[hacker formerly known as [e-mail]]

*** Bug 126952 has been marked as a duplicate of this bug. ***

Comment 21

[Stefan Kost]

yesterday, I tried to compile the mozilla-0.9.9 source again and we still face
the problem, that NSS tries to use the gnu-ld with sun-ld options:
Fortunately this time, there we less things to change :
./security/nss/lib/freebl/Makefile 

DSO_LDOPTS += -shared -Wl,-Bsymbolic,-z,defs,-z,now,-z,text,-M
#DSO_LDOPTS += -shared -Wl,-B,symbolic,-z,defs,-z,now,-z,text,-M,mapfile.Solaris

MKSHLIB += -Bsymbolic -z defs -z now -z text -M
#MKSHLIB += -B symbolic -z defs -z now -z text -M mapfile.Solaris


./security/coreconf/SunOS5.mk
MKSHLIB += -M
#MKSHLIB += -M $(MAPFILE)

1. shouldn't freebl use the settings from coreconf ?
2. couldn't the Makefiles in coreconf check for which ld we are really using ?

Comment 22

[Wan-Teh Chang]

Please try my patch (attachment 56265 [details] [diff] [review]) and let me know if it
works for you.

To answer your questions:
1. freebl needs to augment or override the settings from coreconf
because of its special needs for compiler optimization.  On 32-bit
Solaris and HP-UX we also build freebl twice, once for the pure
32-bit processors and once for the processors with 64-bit
instructions, hence the complexity in freebl's makefile.

2. The Makefiles in coreconf cannot check for which ld we are using
easily.

Comment 23

[hacker formerly known as [e-mail]]

*** Bug 155342 has been marked as a duplicate of this bug. ***

Comment 24

[Wan-Teh Chang]

Attachment: Proposed patch v2.

Updated the patch for the tip of NSS (3.6).

Comment 25

[Wan-Teh Chang]

Proposed patch v2 has been checked into NSS
3.6 (which is not used by the Mozilla trunk
yet).

Comment 26

[Stefan Kost]

I am just trying to build mozilla 1.2b and the problem has not been fixed in
thoses sources. I still need to apply changes to
./directory/c-sdk/build.mk
./security/nss/lib/freebl/Makefile
./security/coreconf/SunOS5.mk
as I had to do for 1.1a.
Furterhmore new problems have been introduced (MKSHLIB += -R '$$ORIGIN' in e.g.
softtoken). I'll post a new bug-report for this.

Comment 27

[hacker formerly known as [e-mail]]

*** Bug 189678 has been marked as a duplicate of this bug. ***