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

[Glynn Clements]

Scott W Mitchell wrote:

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

> ld: can't locate file for: -ldl

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

My suspicion is that this is an oughtright bug rather than just a
"peculiarity". However, you could try performing the configure check
manually in two stages (compile, link) with:

	gcc -c -g -O2 -I/sw/include conftest.c
	gcc -o conftest -g -O2 -L/sw/lib conftest.o -ldl

in case there is a difference between compiling/linking in one step
(as is done by configure) and linking separately (as is done by the
actual build process).

The actual test program is just:

	char dlsym();
	
	int main() {
	dlsym()
	; return 0; }

OTOH, it might be related to the number of linker switches. This is
partly gratuituous; NVIZ2.2/src/Gmakefile shouldn't be explicitly
referencing the X libraries; however, it should be referencing both
OpenGL and Tcl/Tk, and both of those may have the X libraries as
dependencies.

-- 
Glynn Clements <glynn.clements at virgin.net>