The Samba-Bugzilla – Bug 8534
Solaris 8 bin/net, bin/pam_winbind.so need -lintl
Last modified: 2015-11-19 08:43:51 UTC
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 ****
--- 86,92 ----
! LIBNETAPI_LIBS=bin/libnetapi.a -L/usr/local/lib -lintl
*** 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
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
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
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.
I'm trying that now.
/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.