On Fri, Apr 26, 2002 at 01:45:37AM -0700, Justin Erenkrantz wrote:
> I am currently unable to build a SVN that works from the repository
> (I do have a 1682+ snapshot that works). I think I've been able to
> trace it down to the fact that libsvn_ra_dav.la is adding -L/lib and
> -L/usr/lib (see below). No other libtool file that isn't descended
> from libsvn_ra_dav has these flags (so, libsvn_ra, libsvn_client,
> and cmdline/svn all have this -L/lib bogosity), so I think the root
> cause is something that only libsvn_ra_dav links against.
Here's a followup with a hacky solution at end:
- As guessed from my previous message, the culprit does have to do
with neon (as it is the only library used *only* in libsvn_ra_dav).
But, the problem is many-fold with no easy solution.
- I have neon-0.19.4 in /pkg/neon-0.19.4. However, there is an
old neon still living in /usr.
- neon-config prints:
% /pkg/neon-0.19.4/bin/neon-config --libs
-L/pkg/neon-0.19.4/lib -lneon -lz -lexpat
Note that this is in *stark* contrast to ap{ru}-config where --libs
only prints the dependent libs and you must use --link-ld or
--link-libtool to learn how to link against APR. This gets thrown
into NEON_LIBS.
- In the course of linking against my other libraries, for some
unknown reason, libtool decides to add -L/lib and -L/usr/lib in the
intermediate step on the way to the real linker. Even though
-L/lib and -L/usr/lib aren't there initially when SVN calls libtool,
libtool will add these before calling ld.
- Due to the placement of NEON_LIBS (i.e. at the end), -L/lib and
-L/usr/lib appear *before* -L/pkg/neon-0.19.4/lib - therefore,
the linker will find my /usr/lib/libneon.so *before* my
/pkg/neon-0.19.4/lib/libneon.so. Ooooops.
We have now linked against a bad neon. We're screwed.
- So, I decide to try out what would happen if neon-config were
as smart as apr-config - i.e. that it simply passes the path to
the libtool file - /pkg/neon-0.19.4/lib/libneon.la such that
NEON_LIBS is now:
/pkg/neon-0.19.4/lib/libneon.la -lz -lexpat
- Libtool sees the libneon.la file in the right place and
passes /pkg/neon-0.19.4/lib/libneon.so to the linker instead
of specifying -lneon (the -L/lib and -L/usr/lib are still present).
- So, libsvn_ra_dav manages to link against the right neon. Yay.
But, all is not well...
- When we go to install subversion, we pass --mode=install to
install all of the shared objects.
- libtool turns around and does a --mode=relink pass. libtool
becomes cute and decides to normalize all libraries to be
-l<library> - we have now lost our /pkg/neon-0.19.4/lib/libneon.so -
it is now -lneon. We still have our -L/lib and -L/usr/lib hanging
around. Oh no.
- So, on the relink phase, we end up relinking against our bad neon.
What's my solution:
# rpm -e neon neon-devel
Recompile and it works...Frightening in its simplicity considering
how complicated the real problem is. There are a number of steps
along the way that could have been taken by each tool to prevent
this.
This is such a hornet's nest that I don't care to pursue it anymore.
I think libtool is busted a bit (we'd be happy up to the relink
phase with explicit .so's), as is neon a bit (for not allowing us
to know the .la file directly), and as is my system (for some
unknown libtool package adding -L/lib and -L/usr/lib to the
dependency libs).
I hope that in case anyone sees this in the future, my notes
are committed to the ether. And, they have some idea of what
happened and what I did to fix it. This is just a really smelly
problem. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 27 10:04:27 2002