Matt Fago wrote:.
| Peter O'Gorman wrote:
|> Matt Fago wrote:
|> | The main application compiles and links correctly, but a test
|> program --
|> | which links the same convenience libraries -- fails with "ld:
|> Undefined
|> | symbols" corresponding to the global variables in one of the libraries.
|
| The tarball is located at:
God darwin is strange.
The symbols the linker can't find are all common symbols, ranlib's default behavior is not to include common symbols in the archive table of contents. You have many choices for fixing this:
1) RANLIB="ranlib -c" ./configure 2) CPPFLAGS="-fno-common" ./configure 3) edit laminate.c and change "int icomputetan;" to "int icomputetan=0;"
Although this behavior from apple's ranlib and ld is decidedly different, I'm not sure that it constitutes a bug in libtool. Anyway, I'd suggest option 3 above. While you are in there you could remove the other common symbols too, but it isn't really required.
Usually when building shared libtool adds -fno-common to the compile line and -all_load to the link line for convenience libraries, you aren't building shared, so that is not happening, either one (or both) of these would also solve the linking issue.
Not a bug, but perhaps an opportunity to enhance libtool on Darwin. Is it possible to have a future version of libtool do something similar to (1) or (2) above with static libraries on Darwin? I am a bit of a novice in this area -- libtool does its job too well on other platforms.
We had been having trouble with shared libraries a few years ago (mixed with F77 on AIX or HPUX or something -- cannot remember), so that's the reason for the static libs. Perhaps it's time to try shared again.
Thanks for your help. I won't be able to try it for myself until later tonight, but if it worked for you...
Thanks again, Matt
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
