[]
Seems to me that this needs -lz and -ljpeg so that the linker can properly find the libraries /usr/lib/libz.1.dylib and /sw/lib/libjpeg.62.dylib which contain the symbols in question. I don't know enough about the build system to speculate about why this isn't being included, but adding "-lz -ljpeg" to LDFLAGS might do the trick.
It does, and I found a simple patch line for dx's configure.ac which seems logical: This configure.ac tests for libdf by using the flags '-ldf -lz -ljpeg', but then when the test succeeds, it goes ahead and adds only '-ldf' to the LIBS list. The one-liner
perl -pi.bak -e "s|LIB_HDF\=.*ldf.*|LIB_HDF='-ldf -lz -ljpeg'|g" configure.ac
added to the beginning of the dx.info CompileScript makes dx build correctly. (I am now allowed to play with an Xserve which completely compiled dx while I was typing this message :-) On my PowerBook I would never have the patience to make such tests.)
It is not clear, however, if one shouldn't blame hdf for this. I think it is somewhat weird that a static library should have undefined symbols like this. It should probably statically link libdf.a with libz.a and libjpeg.a. The hdf readme files talk about these static versions anyway, not knowing that Darwin will always prefer dynamic over static libraries if it gets the choice.
-- Martin
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
