When I try to build Samba 3.2.0 on Solaris 10 with the with the Sun Studio C compiler (cc), it dies almost immediately with this error: Linking shared library bin/libtalloc.so /usr/ccs/bin/ld: illegal option -- version-script usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit [-a] create an absolute file [-b] do not do special PIC relocations in a.out .. and so on. The problem is that the Solaris ld does not understand --version-script: that's specific to the GNU linker. Looking in the Makefile, I find the problem here: ## Dynamic shared libraries build settings DSO_EXPORTS_CMD=-Wl,--version-script,$(srcdir)/exports/`basename $@ | sed 's/so$$/syms/'` This is hard-coded into Makefile.in; it's not generated by the configure script. Unless I'm missing something (which is quite possible), I don't see how this could work with the Solaris linker.
Correction: The DSO_EXPORTS_CMD is hardcoded into Makefile.in, but DSO_EXPORT, which is what is used in the make target, comes from configure. If the Solaris ld is found in the PATH before the GNU ld at configure time, there won't be any problems. I suppose the most correct thing to do is to see which compiler is being used and deduce the linker, regardless of the path, but I don't know if that's possible.
(In reply to comment #1) > Correction: The DSO_EXPORTS_CMD is hardcoded into Makefile.in, but DSO_EXPORT, That should read "DSO_EXPORTS", with an 'S' at the end.
The problem has been analyzed in (later) bug #5730. Marking this as a duplicate. The problem is that gcc is configured to use the solaris linker, while the gnu linker is found first in the PATH. A workaround is proposed in bug #5730. An approach for detecting the ld that gcc uses is propose in bug #5361 which is the same bug for samba 3.0.28a. Michael *** This bug has been marked as a duplicate of 5730 ***