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

Scott W Mitchell smitch at eos.geog.utoronto.ca
Tue Nov 19 13:42:56 EST 2002

OK, sorry to be answering my own post for the second time, but I found 
the answer, so here it is to make sure it's in the archives for the 
next person... at least I learned and hopefully nobody else (i.e. Glynn 
- thanks for all the help !) will expend effort on this before seeing 
that I have an answer.

Took a break and with a fresh mind, finally paid attention to the fact 
that I only had the .dylib version of libdl, and investigated that 
further.  Turned out that at some point the fink dlcompat package got 
broken into 3 sub-packages, and I didn't have the -dev package that is 
needed to install the .a version of the library, AND it installs a 
"versionless" softlink to libdl.0.dylib, taking care of the version 
number that I worked around in my previous post.

So the answer is that Mac OS X users will need the dlcompat-dev package 
installed if they are using fink - there are also other ways to install 
the dlcompat package, but no matter how they do it, they need those 
bits - you want all three libdl files available:

[fats:GMSL/NVIZ2.2/src] smitch% fink list apropos dlcompat
Information about 1752 packages read in 3 seconds.

  i   dlcompat         20021117-1   Dynamic loading compatibility library
  i   dlcompat-dev     20021117-1   headers and static libraries for 
  i   dlcompat-shlibs  20021117-1   shared libraries for dlcompat
[fats:GMSL/NVIZ2.2/src] smitch% ls -l /sw/lib/libdl*
-rw-r--r--  1 root    unknown  20852 Nov 18 11:28 /sw/lib/libdl.0.dylib
-rw-r--r--  1 root    unknown  15964 Nov 18 11:28 /sw/lib/libdl.a
lrwxr-xr-x  1 smitch  unknown     13 Nov 19 13:28 /sw/lib/libdl.dylib 
-> libdl.0.dylib

On Tuesday, November 19, 2002, at 12:23 PM, Scott W Mitchell wrote:

> A slight update, since it looks like it may explain what's happening;  
> a random brain electron just fired, and I tried changing -ldl to 
> -ldl.0 (i.e. added a "zero" version number since I have 
> /sw/lib/libdl.0.dylib in my system) in a call to gcc, and it compiled 
> the output file despite some TclTk symbol warnings.  So I'm not sure 
> what this means in terms of a portable solution as opposed to Darwin 
> weirdness, but it gets around the error without taking away the DLLIB 
> definition...


>> On Monday, November 18, 2002, at 11:53 PM, Glynn Clements wrote:
>>> Scott W Mitchell wrote:


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


>>> 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>
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5

More information about the grass-dev mailing list