On Tue, Apr 21, 2009 at 05:42:04AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-04-21 00:10:09 Max Bowsher (test unpriv account) napisal(a):
> > There's also the problem that it seems to be duplicating a lot of
> > dependency information that formerly was nicely centralized in
> > build.conf for the most part.
> >
> > IIUC the idea here is to affect the loading path for libs loaded via
> > svn_dso_load ? In which case, why is simply setting an appropriate
> > LD_LIBRARY_PATH not an acceptable solution?
>
> Subversion executables have rpath=$(libdir) which takes precedence over
> LD_LIBRARY_PATH. LD_LIBRARY_PATH specified in libtool wrapper scripts
> has partially wrong value.
Argh.
Note that since recently, pretty much everyone is using a different
version of libtool, namely the one that APR uses. We cannot rely on
libtool doing the same thing for everyone anymore.
For example, with the libtool I am using (system libtool provided by OpenBSD,
nothing else could be persuaded to work), I have to use this hack in my
environment (a Makefile wrapper to build Subversion and most dependencies)
for Subversion to pick up the right libraries:
env LDFLAGS="-L$(PREFIX)/neon/lib -L$(PREFIX)/apr/lib" \
$(SVN_SRCDIR)/configure \
--enable-maintainer-mode \
...
If I don't do that, it will link to APR provided by the operating
system, and to neon provided by the operating system, instead of
my own, self-compiled and more recent versions with debug symbols.
Now, this is just one problem I am seeing, and it may not be related
to your change at all. But I keep seeing myself and others piling hacks
upon hacks around libtool in order to keep it working. It's a waste of
time. Finding the above workaround for my problem took me many hours.
Do you like looking through libtool's file machinery to find out where
and why it keeps setting the wrong LD_LIBRARY_PATH?
I would suggest that instead of piling up more and more hacks to work
around libtool, we make efforts to get rid of it entirely, and pass
our own LDFLAGS to ld, and compile things the way we want, and not
like some million-line non-deterministic shell script wants it.
We pretty much use the GNU toolchain everywhere except Windows, and things
like Solaris or AIX ld etc. can certainly be handled as special cases much
easier than keeping libtool work for everyone.
If we can replace automake madness, we can certainly replace libtool
madness, too. I really wonder why it has not been done yet.
I know there may be difficulties with this I am not aware of since I
have not tried to compile Subversion without libtool yet. However I
would welcome any such attempt and would be willing to invest time
on this once I have it.
Stefan
Received on 2009-04-21 13:26:40 CEST