Last Comment Bug 181382 - Build system assumes using Solaris linker if uname is SunOS
: Build system assumes using Solaris linker if uname is SunOS
Status: RESOLVED FIXED
:
Product: Directory
Classification: Components
Component: LDAP C SDK (show other bugs)
: other
: Sun Solaris
: -- normal (vote)
: mozilla1.3
Assigned To: Dan Mosedale (:dmose)
: Nobody; OK to take it and work on it
Mentors:
: 177113 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-21 18:32 PST by Ari Pollak
Modified: 2003-03-30 16:43 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Force use of Sun ld & ranlib (569 bytes, patch)
2002-12-04 16:29 PST, hacker formerly known as seawood@netscape.com
dmose: review+
asa: approval1.3a+
Details | Diff | Splinter Review

Description Ari Pollak 2002-11-21 18:32:12 PST
If a system's uname is SunOS, c-sdk/build.mk wrongly assumes the user is
building with the solaris ld (even if using GNU ld), and adds the -Blocal option
to ld, which is not recognized by GNU ld and causes the make process to fail.
This is present in the build system in 1.2b, I haven't looked at CVS trunk.
Comment 1 hacker formerly known as seawood@netscape.com 2002-11-21 18:36:44 PST
c-sdk -> LDAP
Looks like it needs the same fix that NSPR used to hardcode the use of Sun's ld.
Comment 2 hacker formerly known as seawood@netscape.com 2002-11-21 18:38:01 PST
.
Comment 3 Ari Pollak 2002-11-21 18:46:19 PST
Two more things - firstly, the build process assumes ranlib can take a -L
option, but GNU ranlib takes no such option, so that part of the build process
fails.
Also, when removing all the hardcoded ld options from build.mk and using GNU ld,
the following error comes up when compiling.. any idea how to alleviate this?

make[4]: Entering directory `/tmp/mozilla/directory/c-sdk/ldap/libraries/libprldap'
./modify.o ./open.o ./os-ip.o ./proxyauthctrl.o ./psearch.o ./referral.o
./regex.o ./rename.o ./request.o ./reslist.o ./result.o ./saslbind.o ./sbind.o
./search.o ./setoption.o ./sort.o ./sortctrl.o ./srchpref.o ./tmplout.o ./ufn.o
./unbind.o ./unescape.o ./url.o ./utf8.o ./vlistctrl.o ./libldap.exp
-L/tmp/mozilla/dist/lib -llber50
/arch/beta/bin/ld:./libldap.exp: file format not recognized; treating as linker
script
/arch/beta/bin/ld:./libldap.exp:1: parse error
make[5]: *** [libldap50.so] Error 1
Comment 4 Mark Smith (:mcs) 2002-11-26 07:10:46 PST
*** Bug 177113 has been marked as a duplicate of this bug. ***
Comment 5 hacker formerly known as seawood@netscape.com 2002-12-04 16:29:25 PST
Created attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib
Comment 6 Dan Mosedale (:dmose) 2002-12-04 16:45:21 PST
Comment on attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib

r=dmose
Comment 7 Ari Pollak 2002-12-04 17:48:05 PST
I don't think the point of this bug came across - the build system assumes the
options specified for the linker are for Solaris' ld, when in reality the linker
used to link the version of CC/C++ could be GNU ld or a different one. The build
system should NOT be forcing the use of Solaris' ld and ranlib, but instead
detecting what kind of ld and ranlib are being used, and set the options
appropriately. If you force the use of a different ld than the one used to link
GCC, you might introduce other problems - which is why configure tests which ld
to use in the first place (but mistakenly the directory does not figure out the
appropriate options).
Comment 8 Nicolas Pioch 2002-12-05 02:04:54 PST
Agreed with comment 7, however the above patch has the benefit of making
the build process not fail, esp. since /usr/ccs/bin/ld exists on the system.

So at least the patch makes all problems disappear... and is a good step forward.
Maybe an additional RFE could be opened so that the build process supports
GNU binutils instead of forcing use of Sun native ones.
(this is however a lesser priority since Mozilla builds finely with Solaris ld)

PS: When I installed GCC 3.2, it bombed out during the compilation process.
I strongly suspect this was due to having GNU binutils (ld/as/ranlib) before
Sun native tools in my PATH.
Since I've disabled GNU binutils, I was successfully able to build and
install GCC 3.2.1 on Solaris. So Mozilla doesn't appear to be the only
application that fails to build on Solaris with GNU binutils
(I haven't investigated more this issue)
Comment 9 Ari Pollak 2002-12-05 08:05:18 PST
Was your GCC compiled with Sun's linker or the GNU linker?
Comment 10 Nicolas Pioch 2002-12-06 01:27:52 PST
I didn't investigate so I can't provide much details, except that
/usr/local/bin is before /usr/ccs/bin in my $PATH

when GNU binutils were installed in /usr/local/bin,
GCC 3.2 didn't compile fully (the C/C++ compiler did compile, it broke later
in the suite, aroung gcj I suspect... unsure)

Now that I've moved GNU binutils outside of my $PATH and outside /usr/local/bin,
GCC 3.2.1 compiled right away.

Sorry for the imprecision, however my conclusion is that as long as a native
as/ld/ranlib/strip is provided in /usr/ccs/bin and is working fine,
I should be using that on Solaris from now on to save me trouble :-)
Comment 11 Ari Pollak 2002-12-06 06:08:21 PST
That's GCC, not Mozilla. If you compiled GCC with Solaris' tools, Mozilla should
compile with the same set of tools. If you compiled GCC with GNU binutils,
Mozilla should do the same. Any program which uses autoconf uses the same logic,
that ld should be the same version used to build the C/C++ compiler.
Comment 12 Ari Pollak 2002-12-06 06:14:37 PST
In any case, a temporary workaround is to --disable-ldap, since for my purposes
it's useless, and all other components build perfectly fine (because they most
likely test for $GNU_LD from configure, hint hint.)
Comment 13 hacker formerly known as seawood@netscape.com 2002-12-06 15:12:45 PST
What problems could be introduced by forcing the use of Solaris' linker instead
of GNU ld?  The output should still be binary compatible.  I think you're
leading up to the bigger question of why are we still creating shared libs using
$LD instead of $CC.

This will cause a problem for cross-compiling though so maybe we should just
fail if GNU ld is detected since it's obviously not supported.  Ultimately, it's
up to the ldap developers to decide if they want to support building with GNU
binutils on solaris.  
Comment 14 Asa Dotzler [:asa] 2002-12-06 15:13:49 PST
Comment on attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib

a=asa for checkin to 1.3a
Comment 15 Ari Pollak 2002-12-06 15:31:22 PST
Such a fix should be OK in the short-term, but seeing as LDAP is the only
component which is incompatible with GNU ld, that bigger problem should probably
be alleviated in the future.
Comment 16 hacker formerly known as seawood@netscape.com 2002-12-17 13:22:25 PST
Actually, LDAP isn't the only component which assumes Sun's ld is the only one
available.  NSPR & NSS also make the same assumption but they've already been
patched using the same fix.

Comment 17 hacker formerly known as seawood@netscape.com 2002-12-17 13:45:41 PST
Patch has been checked in on the client branch & the ldap trunk.
Comment 18 Frankie 2003-03-30 16:43:24 PST
Spam for bug 129472

Note You need to log in before you can comment on or make changes to this bug.