Bug 8534 - Solaris 8 bin/net, bin/pam_winbind.so need -lintl
Solaris 8 bin/net, bin/pam_winbind.so need -lintl
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
Sparc Solaris
: P5 minor
: ---
Assigned To: Björn Jacke
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-10-18 21:47 UTC by Michael Pelletier
Modified: 2015-11-19 08:43 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Pelletier 2011-10-18 21:47:13 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 ****
  LIBTDB_LIBS=-ltdb  -lrt
  TDB_DEPS= -lrt
  LIBNETAPI=bin/libnetapi.a bin/libnetapi.so
! LIBNETAPI_LIBS=bin/libnetapi.a

--- 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

*** 2770,2775 ****
--- 2770,2776 ----
        @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.)
Comment 1 Björn Jacke 2011-10-19 13:07:33 UTC
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.
Comment 2 Michael Pelletier 2011-10-19 14:05:46 UTC
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 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.
Comment 3 Michael Pelletier 2011-10-19 14:08:26 UTC
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
Comment 4 Björn Jacke 2011-10-21 09:30:19 UTC
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.
Comment 5 Michael Pelletier 2011-10-21 12:23:06 UTC
Ah, I see what you mean. I'll mull this further and see what I can come up with.
Comment 6 Michael Pelletier 2011-10-21 16:42:32 UTC
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.
Comment 7 Michael Pelletier 2011-10-21 17:38:49 UTC
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.
Comment 8 Björn Jacke 2011-10-21 18:13:05 UTC
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.
Comment 9 Michael Pelletier 2011-10-24 13:53:52 UTC
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.
Comment 10 Björn Jacke 2015-11-19 08:43:51 UTC
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.