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.
c-sdk -> LDAP Looks like it needs the same fix that NSPR used to hardcode the use of Sun's ld.
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: 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: *** [libldap50.so] Error 1
*** Bug 177113 has been marked as a duplicate of this bug. ***
Comment on attachment 108287 [details] [diff] [review] Force use of Sun ld & ranlib r=dmose
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).
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)
Was your GCC compiled with Sun's linker or the GNU linker?
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 :-)
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.
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 on attachment 108287 [details] [diff] [review] Force use of Sun ld & ranlib a=asa for checkin to 1.3a
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.
Spam for bug 129472