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.
-ldl should already be in the global LIBS, can you please attach your config.log ?
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.
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 */
"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?
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?
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".
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$
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)?
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.
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 ...
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?
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.
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.
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 ?
(In reply to comment #14) > How about just adding -lrt globally to LIBS on all Solaris versions < 10 ? I meant "-ldl" of course
(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.
(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!