Re: Empty allow_undefined_flag in libtool.m4 seems to cause undefined symbol errors on Linux

[Ben Roberts]

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 "address@hidden" at
http://keyserver.ubuntu.com:11371/.