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@virgin.net>