Philip Martin <firstname.lastname@example.org> writes:
> Philip Martin <email@example.com> writes:
>> firstname.lastname@example.org writes:
>>> Author: lundblad
>>> Date: Thu Jan 20 15:05:59 2005
>>> New Revision: 12801
>>> New RA API.
>>> If you like reading tons of wrapper functions, if you like API deprecation
>>> and if you really want to read a somewhat longish commit message, then this
>>> commit is for you. All others: I warned you.
>> This change has broken the build on one of my machines. The machine
>> in question is running a completely standard Debian/testing with
>> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220 $
> I have installed a pristine GNU libtool-1.5.6 and the build works.
It took me a while to understand what is going on, but I think I've
got it now. Debian's modified libtool causes the command line client
link to fail because it links against installed libraries rather than
the build libraries. This doesn't happen for libraries explicitly
specified on the command line, so I get the r12801 libsvn_ra, but the
dependent libraries that are not specified explicitly get resolved to
the installed pre-r12801 versions. That explains why the list of
unresolved symbols was so small--only the new symbols were not found.
I have two sets of libraries installed: Debian's 1.1.1 libraries in
/usr/lib and the development libraries in $HOME/subversion/lib. The
build is configured with --prefix=$HOME/subversion. If I remove the
$HOME/subversion/lib libraries the link works, and the executable that
results is correctly linked to the build libraries. So it appears
that it's libraries installed in --prefix that cause the problem.
Comparing the final link commands I see that GNU's libtool generates a
collect2 command that refers to all four RA libraries and specifies
them with a full path to the .so file in the build tree. Debian's
libtool only mentions libsvn_ra-1.so.
Is this a Debian bug? Is this sort of inter-library dependency
supposed to work? I find the libtool documentation confusing.
that when linking against a libtool library
"you don't need to specify the same `-l' options again: libtool will
do that for you"
but it goes on to say that it doesn't always work and states
"The default, conservative behavior is to avoid linking one library
with another, introducing their inter-dependencies only when a
program is linked with them."
Anyone care to comment?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jan 21 14:57:35 2005