On Sun, 2010-07-04 at 19:27 +0200, Ralf Wildenhues wrote: > Hello Ben, > > any chance you could get your mailer to word-wrap at 72 chars? Thanks.
I can do carriage returns. I'd forgotten about Apple Mail's insistence on format=flowed. My apologies. > * Ben Roberts wrote on Sat, Jul 03, 2010 at 01:55:51AM CEST: > > I've been trying to adapt a set of libraries and programs to use > > autoconf, automake and libtool instead of being manually configured. > > One of the features of this particular package is that there are some > > symbols that should be satisfied at run time, rather than at > > compile-and-link time. > > Is this a feature for this package's shared libraries only, or also for > programs? Initially, I had thought for the shared libraries only. The package includes three different categories of program, and a shared library that allows them to talk to each other. Programs in category A supply some symbols; those in B, others; and those in C, still others. The library contains references to symbols supplied from all categories. The library itself builds and links OK, but when it comes time to build and link the programs, I get complaints about symbols, even though the programs don't call functions in other programs directly; only the library does. It's as though, because I'm linking a program, it explores the whole set of libraries too, to make sure there are no missing symbols. The package contains a library containing "dummy" symbols that are the same name as the missing ones. But I fear that if I link the programs against that library, only the "dummy" functions provided there will be used, when what I would prefer at runtime is a real function provided by one of the other categories of program. > > Now, when I try to build on a Linux box with GNU ld 2.17.50.0.6-9.el5, > > I get errors about undefined symbols. > > Please show an example link command line that fails, including output. make[2]: Entering directory `/home/roberts/apps/pupil-1.3.1/src/cInt-1.3.1/domainid' /bin/sh ../libtool --tag=F77 --mode=link ifort -g -L/usr/java/default/bin/../jre/lib/amd64 -o domainID block.o did.o fixport.o putvalues.o sub_neig_cal.o sub_reg_bondangle.o sub_shiftorigin.o sub_sort.o sub_wave.o main.o ../libIntfc/libPUPIL.la libtool: link: ifort -g -o .libs/domainID block.o did.o fixport.o putvalues.o sub_neig_cal.o sub_reg_bondangle.o sub_shiftorigin.o sub_sort.o sub_wave.o main.o -L/usr/java/default/bin/../jre/lib/amd64 ../libIntfc/.libs/libPUPIL.so -ljava -lverify -Wl,-rpath -Wl,/home/roberts/apps/pupil-1.3.1/lib /opt/intel/fce/10.1.015/lib/libimf.so: warning: warning: feupdateenv is not implemented and will always fail ../libIntfc/.libs/libPUPIL.so: undefined reference to `putcoordinates_' ../libIntfc/.libs/libPUPIL.so: undefined reference to `putforces_' ../libIntfc/.libs/libPUPIL.so: undefined reference to `putresiduetype_' ../libIntfc/.libs/libPUPIL.so: undefined reference to `putatomtype_' make[2]: *** [domainID] Error 1 make[2]: Leaving directory `/home/roberts/apps/pupil-1.3.1/src/cInt-1.3.1/domainid' where "putcoordinates_", "putforces_", "putresiduetype_" and "putatomtype_" are expected to be supplied by other programs, rather than by libraries, at runtime. > > That version of the linker can be persuaded to ignore undefined > > symbols using the "--unresolved-symbols=ignore-all" flag. > > > > When I consulted libtool.m4, I found that there's a variable in there > > that is supposed to contain that flag, or its equivalent on different > > systems: namely, allow_undefined_flag (with a suffix for the compiler > > in certain instances). > > > > The problem: in libtool.m4, allow_undefined_flag is left as an empty > > string on Linux systems. > > Yes, well, GNU/Linux systems allow undefined symbols by default in > shared libraries. > > > Is modifying, and perhaps preparing a patch for, libtool.m4 the best > > approach? An alternative is, no doubt, to write some kind of > > Linux-specific workaround in my configure.ac, but as far as I know > > libtool aims to spare me that kind of thing... > > Well, a patch is acceptable for behavior we can generalize. In order to > find that out, we should have a testsuite addition that tries out the > feature that you would like to see work (showing a small example is > fine, we can easily rework that into a testsuite addition). Then we can > judge it better, and see whether this is good to have generally. > Otherwise, let's then see what you can do instead. Given the nature of the link, that may be tricky. But I'll see what I can do - if it's worth it for us all. Perhaps you can tell me whether what I'm trying to do is even a sensible problem for libtool. Thanks for your help. Cheers, Ben -- For greater security, I support OpenPGP encryption. My public key is available upon request or by searching for "b...@roberts.geek.nz" at http://keyserver.ubuntu.com:11371/. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
