[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r37369 - in trunk: . build (transform_libtool_scripts.sh)

From: Greg Hudson <ghudson_at_mit.edu>
Date: Wed, 22 Apr 2009 00:15:49 -0400

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
Received on 2009-04-22 06:16:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.