You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Max Bowsher (test unpriv account)" <ma...@ukf.net> on 2009/04/20 22:10:09 UTC
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Arfrever Frehtes Taifersar Arahesis wrote:
> Author: arfrever
> Date: Sun Apr 19 12:32:18 2009
> New Revision: 37369
>
> Log:
> Use LD_PRELOAD to ensure that locally built Subversion libraries are used.
>
> * Makefile.in
> (local-all): Depend on 'transform-libtool-scripts' rule.
> (transform-libtool-scripts): New rule which calls
> 'build/transform_libtool_scripts.sh'.
>
> * build/transform_libtool_scripts.sh: New script which adds definitions of
> LD_PRELOAD to libtool wrapper scripts.
This approach seems rather far into the category of unpleasant hack to
me. I certainly feel that if it's a development-time convenience, it's
too ugly to allowed to occur in release builds.
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?
Max.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1831334
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Branko Cibej <br...@xbc.nu>.
Stefan Sperling wrote:
> On Tue, Apr 21, 2009 at 09:45:32PM +0200, Branko Cibej wrote:
>
>> Stefan Sperling wrote:
>>
>>> Tried that. I could not get it to work. I told Justin about it,
>>> but it's not fixed yet.
>>>
>>>
>> Hmm, must be his heartless employer piling too much work on him ...
>> pointer to the thread, please?
>>
>
> Sure, here ya go:
> http://svn.haxx.se/dev/archive-2009-03/0667.shtml
>
Yup, I recall now. So I assume you're on OpenBSD then? ISTR Justin is
more of a MacPerson ... the inscrutable differences between the various
*BSD variants leave me quite unscrewed.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1853239
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Apr 21, 2009 at 09:45:32PM +0200, Branko Cibej wrote:
> Stefan Sperling wrote:
> > Tried that. I could not get it to work. I told Justin about it,
> > but it's not fixed yet.
> >
>
> Hmm, must be his heartless employer piling too much work on him ...
> pointer to the thread, please?
Sure, here ya go:
http://svn.haxx.se/dev/archive-2009-03/0667.shtml
Stefan
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Branko Cibej <br...@xbc.nu>.
Stefan Sperling wrote:
> On Tue, Apr 21, 2009 at 09:18:06PM +0200, Branko Cibej wrote:
>
>> Greg Stein wrote:
>>
>>>> ...
>>>> If we can replace automake madness, we can certainly replace libtool
>>>> madness, too. I really wonder why it has not been done yet.
>>>>
>>>>
>>> Time and inclination. Go ahead and start the work yourself.
>>>
>>>
>> We can always try jlibtool ... at least, if we find problems with it, we
>> can jump up and down on Justin until he fixes 'em. I've found the
>> libtool (and autotools) maintainers to be ... quite unresponsive to
>> suggestions.
>>
>
> Tried that. I could not get it to work. I told Justin about it,
> but it's not fixed yet.
>
Hmm, must be his heartless employer piling too much work on him ...
pointer to the thread, please?
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1847884
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Apr 21, 2009 at 09:18:06PM +0200, Branko Cibej wrote:
> Greg Stein wrote:
> >> ...
> >> If we can replace automake madness, we can certainly replace libtool
> >> madness, too. I really wonder why it has not been done yet.
> >>
> >
> > Time and inclination. Go ahead and start the work yourself.
> >
>
> We can always try jlibtool ... at least, if we find problems with it, we
> can jump up and down on Justin until he fixes 'em. I've found the
> libtool (and autotools) maintainers to be ... quite unresponsive to
> suggestions.
Tried that. I could not get it to work. I told Justin about it,
but it's not fixed yet.
Stefan
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Branko Cibej <br...@xbc.nu>.
Greg Stein wrote:
>> ...
>> If we can replace automake madness, we can certainly replace libtool
>> madness, too. I really wonder why it has not been done yet.
>>
>
> Time and inclination. Go ahead and start the work yourself.
>
We can always try jlibtool ... at least, if we find problems with it, we
can jump up and down on Justin until he fixes 'em. I've found the
libtool (and autotools) maintainers to be ... quite unresponsive to
suggestions.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1847460
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Apr 21, 2009 at 13:26, Stefan Sperling <st...@elego.de> wrote:
>...
> 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.
I doubt anybody disagrees with you.
>...
> If we can replace automake madness, we can certainly replace libtool
> madness, too. I really wonder why it has not been done yet.
Time and inclination. Go ahead and start the work yourself.
>...
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1842275
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Apr 22, 2009 at 12:15:49AM -0400, Greg Hudson wrote:
> On Tue, 2009-04-21 at 12:26 +0100, Stefan Sperling wrote:
> > If we can replace automake madness, we can certainly replace libtool
> > madness, too. I really wonder why it has not been done yet.
>
> automake is a build system organization tool. It's very easy to replace
> on a per-project basis because all it does is translate a description of
> the project sources into a set of Makefile rules, which is (for a given
> project) a very contained problem.
>
> libtool, like autoconf, is a portability tool. It's very hard to
> replace on a per-project basis because very few projects have access to
> hardware for every operating system (and version) that they might want
> to be built on, or sufficient expertise in the workings of shared
> libraries on those systems. libtool also does some really heroic stuff,
> like relinking binaries for use in the build tree to address the
> LD_LIBRARY_PATH/DT_RPATH priority issue.
>
> That said, if you abandon libtool, certain options open up to you on
> certain platforms. You can pass --enable-new-dtags on Linux to use
> DT_RUNPATH (which doesn't take priority over LD_LIBRARY_PATH) instead of
> DT_RPATH (which does). You can supply a list of symbol names to export,
> causing other symbol names to remain hidden. You can do symbol
> versioning, which would allow multiple versions of the Subversion
> libraries to coexist within an application (which is probably not a good
> idea, admittedly).
Thanks, good points. Sounds like I'll have a lot of learning to do
before I can tackle this... *sigh*
Stefan
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Greg Hudson <gh...@mit.edu>.
On Tue, 2009-04-21 at 12:26 +0100, Stefan Sperling wrote:
> If we can replace automake madness, we can certainly replace libtool
> madness, too. I really wonder why it has not been done yet.
automake is a build system organization tool. It's very easy to replace
on a per-project basis because all it does is translate a description of
the project sources into a set of Makefile rules, which is (for a given
project) a very contained problem.
libtool, like autoconf, is a portability tool. It's very hard to
replace on a per-project basis because very few projects have access to
hardware for every operating system (and version) that they might want
to be built on, or sufficient expertise in the workings of shared
libraries on those systems. libtool also does some really heroic stuff,
like relinking binaries for use in the build tree to address the
LD_LIBRARY_PATH/DT_RPATH priority issue.
That said, if you abandon libtool, certain options open up to you on
certain platforms. You can pass --enable-new-dtags on Linux to use
DT_RUNPATH (which doesn't take priority over LD_LIBRARY_PATH) instead of
DT_RPATH (which does). You can supply a list of symbol names to export,
causing other symbol names to remain hidden. You can do symbol
versioning, which would allow multiple versions of the Subversion
libraries to coexist within an application (which is probably not a good
idea, admittedly).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1854090
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Stefan Sperling <st...@elego.de>.
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
Re: svn commit: r37369 - in trunk: . build
(transform_libtool_scripts.sh)
Posted by Arfrever Frehtes Taifersar Arahesis <Ar...@GMail.Com>.
2009-04-21 00:10:09 Max Bowsher (test unpriv account) napisał(a):
> Arfrever Frehtes Taifersar Arahesis wrote:
> > Author: arfrever
> > Date: Sun Apr 19 12:32:18 2009
> > New Revision: 37369
> >
> > Log:
> > Use LD_PRELOAD to ensure that locally built Subversion libraries are used.
> >
> > * Makefile.in
> > (local-all): Depend on 'transform-libtool-scripts' rule.
> > (transform-libtool-scripts): New rule which calls
> > 'build/transform_libtool_scripts.sh'.
> >
> > * build/transform_libtool_scripts.sh: New script which adds definitions of
> > LD_PRELOAD to libtool wrapper scripts.
>
>
> This approach seems rather far into the category of unpleasant hack to
> me. I certainly feel that if it's a development-time convenience, it's
> too ugly to allowed to occur in release builds.
Currently local-all rule depends on transform-libtool-scripts rule, but
I think that a new rule called e.g. 'dev' could be created and it would
depend on transform-libtool-scripts rule.
> 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.
--
Arfrever Frehtes Taifersar Arahesis