You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2009/03/01 12:26:26 UTC
Re: svn commit: r36153 - in trunk: . build
Justin Erenkrantz <je...@apache.org> writes:
> As I said, I think a configure option that lets you specify the path
> to libtool would make it easier - IOW, the patch below.
>
> If we go and build a custom libtool thru autoconf, then we have to
> drag in all of the clumsy code to deal with different libtool
> versions. And, we'll be yet again forced to hop on the maddening
> libtool train when there is no real need to do so.
>
> I don't know why you think you *need* the autoconf-fu in order to use
> GNU libtool. If you installed GNU libtool 2.x yourself, there is a
> glibtool or libtool or whatever binary already there - just point to
> it. The muckin' with GNU libtool at configure-time has always been
> unnecessary. -- justin
>
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 36180)
> +++ configure.ac (working copy)
> @@ -168,8 +168,13 @@
> [Defined to be the path to the installed locale dirs])
>
> dnl Check for libtool -- we'll definitely need it for all our shared libs!
> -echo "using APR's libtool"
> -sh_libtool="`$apr_config --apr-libtool`"
> +AC_ARG_WITH(custom-libtool,
> +AS_HELP_STRING([--with-custom-libtool=PATH],
> + [Specify the command to run libtool]),
> + [ AC_MSG_NOTICE([using $withval as libtool])
> + sh_libtool="$withval" ],
> + [ AC_MSG_NOTICE([using APR's libtool])
> + sh_libtool="`$apr_config --apr-libtool`" ])
> LIBTOOL="$sh_libtool"
> SVN_LIBTOOL="$sh_libtool"
> AC_SUBST(SVN_LIBTOOL)
If it were that simple I would not be complaining, I would have made a
similar change. The problem is that I don't have a suitable libtool
script to use. The libtool script that I want to use is the one that
was created by the "muckin' around" and that script no longer gets
created. The generic /usr/bin/libtool isn't the same as the script
that used to be created.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1250141
Re: svn commit: r36153 - in trunk: . build
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Mar 1, 2009 at 9:10 AM, Philip Martin <ph...@codematters.co.uk> wrote:
> Sorry, my mistake, I'd gone back to 1.5 to try and see what was
> changing. With 2.2.6 the diff is much smaller: 23 new lines inserted.
> I still don't know which of those lines matter. Does it matter that
> LTCFLAGS changes? What about sys_lib_search_path_spec, or postdeps?
Hard to tell without seeing the diff. =) -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1251352
Re: svn commit: r36153 - in trunk: . build
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@apache.org> writes:
> Then it sounds like that isn't the same libtool that you were running
> against before. The diffs should be relatively minor (mine is in the
> order of 60 lines once you factor out the tags which is ~800 lines of
> fortran and gcj support, etc, etc.). The fact it isn't likely means
> you are confused about what version of libtool you are using. Are
> your libtoolize and libtool the same version? IMO, this is all the
> more reason that Subversion shouldn't be involved at all in this
> process. -- justin
Sorry, my mistake, I'd gone back to 1.5 to try and see what was
changing. With 2.2.6 the diff is much smaller: 23 new lines inserted.
I still don't know which of those lines matter. Does it matter that
LTCFLAGS changes? What about sys_lib_search_path_spec, or postdeps?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1251348
Re: svn commit: r36153 - in trunk: . build
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Mar 1, 2009 at 8:39 AM, Philip Martin <ph...@codematters.co.uk> wrote:
> Read my second email in this thread--it's much slower. From the other
> thread I guess that's because it builds both shared and static
> libraries and I only want to build one.
I'm fixing that at the moment - right now, we're ignoring
--disable-shared/--disable-static.
> diff shows about 7000 lines
> changed so there could be other things as well. I suppose I could
> create my on modified version of the script, but why should I have to
> do that when Subversion used to do it automatically. How many of the
> 7000 changes matter?
Then it sounds like that isn't the same libtool that you were running
against before. The diffs should be relatively minor (mine is in the
order of 60 lines once you factor out the tags which is ~800 lines of
fortran and gcj support, etc, etc.). The fact it isn't likely means
you are confused about what version of libtool you are using. Are
your libtoolize and libtool the same version? IMO, this is all the
more reason that Subversion shouldn't be involved at all in this
process. -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1251289
Re: svn commit: r36153 - in trunk: . build
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <je...@apache.org> writes:
> Why not? In all cases here, it is almost always very similar (esp.
> with GNU libtool 2.2.6) - the only difference here is that it doesn't
> have the same tag config (duh). Have you tried just pointing at it?
> What breaks, if anything? -- justin
Read my second email in this thread--it's much slower. From the other
thread I guess that's because it builds both shared and static
libraries and I only want to build one. diff shows about 7000 lines
changed so there could be other things as well. I suppose I could
create my on modified version of the script, but why should I have to
do that when Subversion used to do it automatically. How many of the
7000 changes matter?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1251195
Re: svn commit: r36153 - in trunk: . build
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Mar 1, 2009 at 4:26 AM, Philip Martin <ph...@codematters.co.uk> wrote:
> If it were that simple I would not be complaining, I would have made a
> similar change. The problem is that I don't have a suitable libtool
> script to use. The libtool script that I want to use is the one that
> was created by the "muckin' around" and that script no longer gets
> created. The generic /usr/bin/libtool isn't the same as the script
> that used to be created.
Why not? In all cases here, it is almost always very similar (esp.
with GNU libtool 2.2.6) - the only difference here is that it doesn't
have the same tag config (duh). Have you tried just pointing at it?
What breaks, if anything? -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1251128