The -lintl library is not included by the configure on Solaris 8 (and at least Solaris 9 as well, per http://tinyurl.com/6aopovn), which is required in order to link bin/net and bin/pam_winbind.so. I gather from online information that the GNU libintl is needed, and the antique Solaris libintl can't be safely used. I worked around this as follows: *** Makefile.orig Tue Oct 18 17:10:01 2011 --- Makefile Tue Oct 18 17:23:47 2011 *************** *** 86,92 **** LIBTDB_LIBS=-ltdb -lrt TDB_DEPS= -lrt LIBNETAPI=bin/libnetapi.a bin/libnetapi.so ! LIBNETAPI_LIBS=bin/libnetapi.a LIBSMBCLIENT_LIBS=bin/libsmbclient.a LIBSMBSHAREMODES_LIBS=-lsmbsharemodes --- 86,92 ---- LIBTDB_LIBS=-ltdb -lrt TDB_DEPS= -lrt LIBNETAPI=bin/libnetapi.a bin/libnetapi.so ! LIBNETAPI_LIBS=bin/libnetapi.a -L/usr/local/lib -lintl LIBSMBCLIENT_LIBS=bin/libsmbclient.a LIBSMBSHAREMODES_LIBS=-lsmbsharemodes *************** *** 2770,2775 **** --- 2770,2776 ---- bin/pam_winbind.so: $(BINARY_PREREQS) $(PAM_WINBIND_OBJ) $(LIBTALLOC) $(LIBWBCLIENT) @echo "Linking shared library $@" @$(SHLD) $(LDSHFLAGS) -o $@ $(PAM_WINBIND_OBJ) -lpam \ + -L/usr/local/lib -lintl \ $(LIBREPLACE_LIBS) $(LIBTALLOC_LIBS) $(LIBWBCLIENT_LIBS) -Wl,-soname=`basename $@` ########## -------------------- (Should the "-lpam" there be "$(AUTH_LIBS)" instead? Also in bin/pam_smbpass.so and test_map_modules?) (With this workaround plus 8531 and 8532, I have completed a build of Samba 3.6.0 on Solaris 8. I can't run "make test" since I don't have Python for Solaris 8, so wish me luck.)
IIRC this problem pops up on some Solaris systems because you have two different but equally named libintl libraries installed on your system which are incompatible. in /usr/local/ you have the GNU version and in /usr/ you have the native Solaris version, right? Currently I see no clean way for us to make sure that we detect and link the right version in a predictable way.
The /usr/lib/libintl.so which comes with Solaris 8 is v1: lrwxrwxrwx 1 root root 14 Jul 22 2006 /usr/lib/libintl.so -> ./libintl.so.1 -rwxr-xr-x 1 root bin 2484 Jan 5 2000 /usr/lib/libintl.so.1 Its namelist, as compared to GNU libintl in /usr/local/lib, is sharply limited: bedsrv01$ nm /usr/lib/libintl.so 00000000 A SUNW_0.7 00000000 A SUNW_0.8 00000000 A SUNW_1.1 00000000 A SUNWprivate_1.1 000002ec D _DYNAMIC 000004d6 b _END_ 00000000 A _PROCEDURE_LINKAGE_TABLE_ 00000000 r _START_ 00000000 A _edata 000004d6 B _end 000004d6 B _etext 00000000 A bindtextdomain 00000000 A dcgettext 00000000 A dgettext 00000000 A gettext 00000000 A textdomain bedsrv01$ Solaris 9 looks about the same. The GNU libintl.so, on the other hand, has the function which pam_winbind.o is looking for: bedsrv01$ nm /usr/local/lib/libintl.so | grep _dgettext 000028f4 T libintl_dgettext bedsrv01$ Configure could check each libintl.so it locates for the presence of libintl_dgettext, for example, and if it doesn't find it, it would know that library is not usable. It would then be able to select the proper one if it's available, or bail out if none of them are usable.
You could also do something similar to what you're already doing with iconv: --with-libiconv=BASEDIR Use libiconv in BASEDIR/lib and BASEDIR/include (default=auto) As in: --with-libintl=BASEDIR
but in the case of iconv the libraries have different names IIRC. Changing the search order of the library paths fixes the problem for your setup but it may break things for other people at the same time. So just changing the library path order is not a real fix for this. Maybe we should simply disable i18n/gettext support on Solaris because of that crap.
Ah, I see what you mean. I'll mull this further and see what I can come up with.
What if we static link the GNU libintl on Solaris? It's not all that big. LIBNETAPI_LIBS=@LIBNETAPI_ILBS@ /usr/local/lib/libintl.a I'm trying that now.
Linking bin/net /usr/local/lib/libintl.a(dcigettext.o): In function `_nl_find_msg': dcigettext.c:(.text+0x804): undefined reference to `libiconv' dcigettext.c:(.text+0xa24): undefined reference to `libiconv_open' /usr/local/lib/libintl.a(relocatable.o): In function `libintl_set_relocation_prefix': relocatable.c:(.text+0x4c): undefined reference to `libiconv_set_relocation_prefix' relocatable.c:(.text+0xc8): undefined reference to `libiconv_set_relocation_prefix' collect2: ld returned 1 exit status make: *** [bin/net] Error 1 Adding "-liconv" before the /usr/local/lib/libintl.a seems to have worked to fix this issue.
this is another side effect which makes this work for you because libiconv is . I more and more think that disabling gettext support is the best option. Just wondering if we should disable it on Solaris in ANY case or if we should just disable it if we found the conflicting GNU libs along with the native libs.
I'm not clear on why you think identifying and static-linking the correct libintl isn't a suitable way to address it. The static library is only 62,570 bytes. I got a good build which passed self-tests. I think it would be best to disable gettext only if a suitable libintl can't be found, rather than on any Solaris.
the old autoconf build system is gone since a while now. If you see a similar issue with the currect waf build, please file another new bug for that. Thanks Björn