Re: avoiding C++, Fortran tags
Libtool 1.5 seems like it currently requires a F77 compiler, but I'm trying to build on Darwin with Apple's gcc. For now I can gladly use Paolo's backport of AC_LIBTOOL_TAGS. Thanks! Is there a plan to release an interim 1.5.1 libtool version with this patch, or is 1.6 coming out soon? Regarding the patch: Where is the proper location for installing the patch if I want it available on a system level? To not configure C++/F77 I would then call AC_LIBTOOL_TAGS([]) before the call to AC_PROG_LIBTOOL? Thanks all! - Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: avoiding C++, Fortran tags
Bob Friesenhahn wrote: On Wed, 3 Dec 2003, Matt Fago wrote: Is there a plan to release an interim 1.5.1 libtool version with this patch, or is 1.6 coming out soon? At this moment any release plans are pointless since the site that hosts Libtool CVS has been temporarily shut down due to being hacked. It may be a week or two before we have access to the sources again. See http://savannah.gnu.org/statement.html for info on this event. Yes, bad news indeed. I have not been following libtool 1.6 development and do not know if it is likely to be released in the near future or in (say) a few months or longer. All assuming CVS is back up soon of course. BTW, answering one of my own questions, the patch works as advertised for me when called as: AC_LIBTOOL_TAGS([]) AC_PROG_LIBTOOL although I'm still not exactly sure where the "proper" place is to put the patch at a system-level. - Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Darwin, convenience libs, and global symbols
I am porting a package to Darwin (compiles fine on Linux) consisting of several convenience libraries, a few test programs, and an application. I'm using Autoconf 2.58, automake 1.7.9, and libtool 1.5 (with the AC_LIBTOOL_TAGS patch). 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 only difference I can think of: the library is constructed by the same Makefile.am as the test program in question (something I do not want to change). Any ideas? I'd be happy to supply any code. Thanks, Matt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Darwin, convenience libs, and global symbols
Peter O'Gorman wrote: 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
