[GRASS5] CVS version of grass5 failing to compile nviz & r.in.gdal because of -ldl flag

[Scott W Mitchell]

I'm sorry, I didn't search for all the possibilities when I concluded  
that libdl was not on my system.  Turns out there's a libdl.0.dylib in  
/sw/lib, which is where the fink packaging system puts things under Mac  
OS.  Not sure how I managed to miss that, must have been dumb mistake.

Sure enough, configure found it:

configure:4491: checking for dlsym in -ldl
configure:4508: gcc -o conftest -g -O2    -I/sw/include   -L/sw/lib  
conftest.c -
ldl   1>&5
configure:4535: checking for iconv
...


So, then the question is why the nviz compile can't find it:

/Volumes/newData/smitchHome/src/grass/src.contrib/GMSL/NVIZ2.2/src
   make -f OBJ.powerpc-apple-darwin6.1/make.rules

gcc  
-L/Volumes/newData/smitchHome/src/grass/src/libes/LIB.powerpc-apple- 
darwin6.1 -L/sw/lib -o nvwish OBJ.powerpc-apple-darwin6.1/nvizAppInit.o  
OBJ.powerpc-apple-darwin6.1/change_view.o  
OBJ.powerpc-apple-darwin6.1/draw.o OBJ.powerpc-apple-darwin6.1/exag.o  
OBJ.powerpc-apple-darwin6.1/glwrappers.o  
OBJ.powerpc-apple-darwin6.1/init_commands.o  
OBJ.powerpc-apple-darwin6.1/lights.o  
OBJ.powerpc-apple-darwin6.1/map_obj.o  
OBJ.powerpc-apple-darwin6.1/misc.o  
OBJ.powerpc-apple-darwin6.1/nviz_init.o  
OBJ.powerpc-apple-darwin6.1/position.o  
OBJ.powerpc-apple-darwin6.1/quick_draw.o  
OBJ.powerpc-apple-darwin6.1/anim_support.o  
OBJ.powerpc-apple-darwin6.1/cutplane_obj.o  
OBJ.powerpc-apple-darwin6.1/script_support.o  
OBJ.powerpc-apple-darwin6.1/do_zoom.o  
OBJ.powerpc-apple-darwin6.1/label.o  
OBJ.powerpc-apple-darwin6.1/nvizMain.o  
OBJ.powerpc-apple-darwin6.1/togl.o  
OBJ.powerpc-apple-darwin6.1/togl_cb.o  
OBJ.powerpc-apple-darwin6.1/query_postgr.o  
OBJ.powerpc-apple-darwin6.1/openvect.o  
OBJ.powerpc-apple-darwin6.1/getCat.o  
OBJ.powerpc-apple-darwin6.1/buildInfxQry.o  
OBJ.powerpc-apple-darwin6.1/runInfxQry.o  
/Volumes/newData/smitchHome/src/grass/src/libes/ogsf/LIB.powerpc-apple- 
darwin6.1/libgsf.a  
/Volumes/newData/smitchHome/src/grass/src/libes/libimage/LIB.powerpc- 
apple-darwin6.1/libimage.a \
-lbitmap -llinkm -lvect -ldig2 \
-lgis  -lz   \
-ldatetime   -ltk   -L/usr/X11R6/lib  -lSM -lICE -lX11   -ltcl   
-L/usr/X11R6/lib  -lGLU  -L/usr/X11R6/lib  -lGL   -lSM -lICE -lX11  
-lXmu -lXext  -ldl -lz    -L/usr/X11R6/lib    -ltiff  -lSM -lICE -lX11
ld: can't locate file for: -ldl
make[1]: *** [nvwish] Error 1
make: *** [nvwish] Error 2


I guess it has to do with Darwin peculiarities re: shared libs, but we  
just hit the walls of my understanding again.  I don't see anything  
that explains it to me at  
http://fink.sourceforge.net/doc/porting/shared.php

I THOUGHT it might be to do with the problem reported at:
http://www.opendarwin.org/en/faq.php#linksym

because that says all the -L and -l statements need to be listed AFTER  
the object files, and that isn't the case in the failed compile above.   
But typing it in all manually at the command prompt so that the -L's  
and -l's come last did not change / get rid of the ld error for me.

Well, for now my workaround is to not include $DLLIB in the NVIZ  
compile, and I'll leave it at that for now, but can help track this  
down over time if needed.

Thanks,

Scott

On Monday, November 18, 2002, at 11:53 PM, Glynn Clements wrote:

>
> Scott W Mitchell wrote:
>
>> Just tried to compile today's CVS version of GRASS5 (is CVS HEAD the
>> right terminology if I've just checked out / updated the grass
>> directory without specifying any tags?) so I could get the "history
>> with r.mapcalc" working.  I've posted separately about the fact that
>> r.mapcalc itself won't compile on my Linux box.
>>
>> But here on my Darwin/MacOS X machine, everything apparently compiled
>> (including r.mapcalc, and it's recording the formulae used now - yay !
>> Thanks, Glynn !) except for r.in.gdal and NVIZ 2.2.
>>
>> Digging deeper, the error was the same in both cases - when it tries  
>> to
>> link everything together there's a lib flag for the DL library (-ldl)
>> and libdl isn't found.  IF I understand correctly (and that's a big
>> if), libopen() etc are provided by dlcompat in this OS so there is no
>> such DL library.
>>
>> So... I tracked down the -ldl call to the head file, and just made the
>> DLLIB variable empty in my copy of head.powerpc-apple-darwin6.1 - and
>> then tried to compile NVIZ and it does so without an error.
>>
>> Is that the appropriate fix ?  NVIZ seems to be working now, anyways.
>>
>> For some reason, taking the DLLIB definition away doesn't stop the
>> compile for r.in.gdal from trying to load libdl so I still have that
>> error, but will keep digging for it...
>
> 1. The use of $(DLLIB) by NVIZ is gratuitous; the NVWISH2.2 binary
> doesn't directly call dlopen() etc.
>
> It's possible that one of the libraries against which NVIZ is linked
> may require libdl on some platforms; however, that should be handled
> by configure when detecting the library in question (libtcl and libGL
> are both candidates; configure *does* check for $DLLIB when checking
> libtcl).
>
> 2. r.in.gdal *does* use dlopen() unless you use the --with-gdal
> configure switch. However, this is handled by configure, which adds
> $DLLIB to GDAL_LIBS where appropriate (i.e. when you aren't using
> --with-gdal).
>
> 3. However, neither of the above should really matter, because DLLIB
> should be empty unless configure actually finds dlsym() in libdl.
> Specifically, configure:
>
> a) checks whether dlsym() is available without any additional
> switches; if it is, then DLLIB is set to empty.
>
> b) otherwise, it checks whether dlsym() is available when linking
> against the "dl" library (i.e. with "-ldl"); if it is, then DLLIB is
> set to "-ldl".
>
> c) otherwise, DLLIB is set to empty.
>
> The resulting value of DLLIB is used in the rest of the configure
> script, and is substituted when converting src/CMD/head/head.in into
> src/CMD/head/head (which is later renamed to e.g.
> src/CMD/head/head.powerpc-apple-darwin6.1).
>
> So, I'm curious as to why configure decided to set DLLIB to "-ldl" if
> you don't have a library with that name.
>
> -- 
> Glynn Clements <glynn.clements at virgin.net>
>