Bug 8532 - Solaris 8 needs LIBS+=-ldl in order to build libnetapi.so.0
Solaris 8 needs LIBS+=-ldl in order to build libnetapi.so.0
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
3.6.0
Sparc Solaris
: P5 minor
: ---
Assigned To: Björn Jacke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-18 20:28 UTC by Michael Pelletier
Modified: 2011-10-24 14:07 UTC (History)
0 users

See Also:


Attachments
Config.log (3.98 MB, application/octet-stream)
2011-10-19 13:05 UTC, Michael Pelletier
no flags Details
conftest.c from configure for the -ldl-needed test (4.41 KB, application/octet-stream)
2011-10-21 16:04 UTC, Michael Pelletier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Pelletier 2011-10-18 20:28:13 UTC
Solaris 8 gcc 4.4.3:

Compiling dynconfig.c
Linking shared library bin/libnetapi.so.0
lib/module.o: In function `do_smb_load_module':
module.c:(.text+0x20): undefined reference to `dlopen'
module.c:(.text+0x28): undefined reference to `dlerror'
module.c:(.text+0xdc): undefined reference to `dlsym'
module.c:(.text+0xe4): undefined reference to `dlerror'
module.c:(.text+0x158): undefined reference to `dlclose'
module.c:(.text+0x268): undefined reference to `dlclose'
collect2: ld returned 1 exit status
make: *** [bin/libnetapi.so.0] Error 1

The "dlopen," etc functions are in the libdl.so library on Solaris 8. I worked around by simply adding -ldl to the end of LIBS= in the Makefile.
Comment 1 Björn Jacke 2011-10-19 12:49:41 UTC
-ldl should already be in the global LIBS, can you please attach your config.log ?
Comment 2 Michael Pelletier 2011-10-19 13:03:02 UTC
It appears that the configure script is not finding the /usr/lib/libdl.so in order to set the LIBDL variable. Line 59 of the Makefile has "LIBDL=", excerpt from config.log. Config.log is attached.
Comment 3 Michael Pelletier 2011-10-19 13:05:53 UTC
Created attachment 7010 [details]
Config.log

configure:10946: checking for library containing dlopen
configure:10977: gcc -o conftest -O  -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OF
FSET_BITS=64 -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent
 -I./librpc -I./.. -I./../lib/popt  -lthread conftest.c  >&5
configure:10977: $? = 0
configure:10994: result: none required

...

configure:11116: checking for prototype void *dlopen(const char* filename, unsig
ned int flags)
configure:11136: gcc -c -O  -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS
=64 -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent -I./libr
pc -I./.. -I./../lib/popt conftest.c >&5
conftest.c:208: error: conflicting types for 'dlopen'
/usr/include/dlfcn.h:83: note: previous declaration of 'dlopen' was here
configure:11136: $? = 1
configure: failed program was:
| /* confdefs.h */
Comment 4 Björn Jacke 2011-10-21 09:16:16 UTC
"checking for library containing dlopen ... none required"  would be normal for Solaris 10 because Sun made the dl* functions available in libc directly. In Solaris 8 this should not be the case. On our Solaris 8 box the check works as expected:

checking for library containing dlopen... -ldl

and along with the -ldl is added to the global LIBS.

can you try to investigate why on your Solaris 8 box dlopen ... none required is detected?
Comment 5 Michael Pelletier 2011-10-21 12:20:18 UTC
Björn, I'm not too familiar with the ins and outs of autoconfig except for a spot of work I had to do to get ClamAV to build on Solaris 2.6 (ugh, don't ask). Can you recommend some test procedures? Can I just paste that conftest.c into a file and run the gcc command indicated to build it, or are there other switches and dials?
Comment 6 Björn Jacke 2011-10-21 12:40:13 UTC
yes taking the conftest.c sniplet and compile it like configure does is a good starting point. Please find out what makes it compile because it *should* fail to compile on Solaris 8 unless you add "-ldl".
Comment 7 Michael Pelletier 2011-10-21 16:04:13 UTC
Created attachment 7017 [details]
conftest.c from configure for the -ldl-needed test

bedsrv01$ gcc -o conftest -O  -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt  -lthread dltest.c
bedsrv01$ ./conftest
bedsrv01$ echo $?
0
bedsrv01$ ldd conftest
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
bedsrv01$
Comment 8 Michael Pelletier 2011-10-21 16:15:28 UTC
Is the issue here that the configure is checking on the creation of an executable while the problem occurs when linking a shared library (libnetapi.so.0)?
Comment 9 Michael Pelletier 2011-10-21 17:07:59 UTC
Adding -ldl to SHLD_DSO right before the -o, and removing it from LIBS, seems to have worked, so that narrows down the scope a bit.
Comment 10 Björn Jacke 2011-10-21 17:44:22 UTC
that was clear that -ldl makes it work. But it's missing there because the configure test for the needed library for dlopen succeds where it should fail. I suspect your gcc might try to do something good. can you test if the studio compiler behaves the same? It might be that your gcc silently links in libdl for programs but not for shared libraries ...
Comment 11 Michael Pelletier 2011-10-21 17:50:49 UTC
GCC is the only compiler I have for this Solaris 8 box. If we were on HP-UX, I have the HP ANSI C compiler too, but no such luck on Solaris. Any other tests I can perform?
Comment 12 Björn Jacke 2011-10-21 17:55:12 UTC
did Oracle make the studio compiler $$-ware now? At least when Solaris was still a Sun product, the studio compiler was free as in beer.
Comment 13 Michael Pelletier 2011-10-21 19:16:09 UTC
Ah, I see - I'd just never used it, always been a gcc maven since 1988 or so, on an Altos 68000. My first big C project was massaging the Rogue and Hack code so it would work with a compiler with an 8-character variable name limit, and gcc was a refreshing change.

It looks like I'd need to find Sun Studio 11, and Oracle doesn't appear to have it on their site. Not surprising, I suppose.
Comment 14 Björn Jacke 2011-10-21 19:26:33 UTC
never mind, on our solaris 8 machine there the studio compiler doesn't link in libldl, neither does our gcc 3.4. Looks pretty much like your gcc4 does that job and misses to do the same thing for shared libs. I love this piece of gnu software on Solaris.

How about just adding -lrt globally to LIBS on all Solaris versions < 10 ?
Comment 15 Björn Jacke 2011-10-21 19:27:24 UTC
(In reply to comment #14)
> How about just adding -lrt globally to LIBS on all Solaris versions < 10 ?

I meant "-ldl" of course
Comment 16 Michael Pelletier 2011-10-21 20:31:32 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > How about just adding -lrt globally to LIBS on all Solaris versions < 10 ?
> 
> I meant "-ldl" of course

That's what I did in my Makefile, and everything went very well, so I reckon that'd be the easiest way to fix it. No sense spending much time or complexity on it considering that Solaris 11 is coming out soon.
Comment 17 Michael Pelletier 2011-10-24 14:07:47 UTC
(In reply to comment #14)
> never mind, on our solaris 8 machine there the studio compiler doesn't link in
> libldl, neither does our gcc 3.4. Looks pretty much like your gcc4 does that
> job and misses to do the same thing for shared libs. I love this piece of gnu
> software on Solaris.

I had to build GCC 4 for not only Solaris 8, but Solaris 2.6 and 7 as well, in order to build the latest ClamAV... what an adventure THAT was. Phew!