Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Build system assumes using Solaris linker if uname is SunOS

RESOLVED FIXED in mozilla1.3


15 years ago
15 years ago


(Reporter: Ari Pollak, Assigned: dmose)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
If a system's uname is SunOS, c-sdk/ 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.
c-sdk -> LDAP
Looks like it needs the same fix that NSPR used to hardcode the use of Sun's ld.
Assignee: seawood → mcs
Component: Build Config → LDAP C SDK
Product: Browser → Directory
QA Contact: granrose → nobody
Version: Trunk → other
Assignee: mcs → dmose

Comment 3

15 years ago
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
Also, when removing all the hardcoded ld options from 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
/arch/beta/bin/ld:./libldap.exp:1: parse error
make[5]: *** [] Error 1


15 years ago
Hardware: PC → Sun

Comment 4

15 years ago
*** Bug 177113 has been marked as a duplicate of this bug. ***
Created attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib
Attachment #108287 - Flags: review?(dmose)

Comment 6

15 years ago
Comment on attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib

Attachment #108287 - Flags: review?(dmose) → review+
Attachment #108287 - Flags: superreview?(mcs)

Comment 7

15 years ago
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).
Attachment #108287 - Flags: superreview?(mcs) → superreview?(bryner)

Comment 8

15 years ago
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

15 years ago
Was your GCC compiled with Sun's linker or the GNU linker?

Comment 10

15 years ago
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

15 years ago
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

15 years ago
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.)
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

15 years ago
Comment on attachment 108287 [details] [diff] [review]
Force use of Sun ld & ranlib

a=asa for checkin to 1.3a
Attachment #108287 - Flags: approval1.3a+
Attachment #108287 - Flags: superreview?(bryner)

Comment 15

15 years ago
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.
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.

Patch has been checked in on the client branch & the ldap trunk.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.3

Comment 18

15 years ago
Spam for bug 129472
QA Contact: nobody → nobody
You need to log in before you can comment on or make changes to this bug.