You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jani Averbach <ja...@jaa.iki.fi> on 2005/01/04 21:23:11 UTC
[PATCH] libtool with --tag=XXX (Was: make swig-py won't compile)
On 2005-01-03 12:57-0800, Justin Erenkrantz wrote:
> --On Monday, January 3, 2005 1:52 PM -0700 Jani Averbach <ja...@jaa.iki.fi>
> wrote:
>
> >Updated libtool to the version 1.5.10, checked that
> >/usr/bin/cc is gcc and checked that I have not set any CC
> >etc. env. variables.
>
> Your output had:
>
> /bin/sh /home/jaa/tmpfs/build/trunk/libtool --silent
> --mode=compile x86_64-pc-linux-gnu-gcc ...
>
> Python looks to have been compiled with that compiler. I actually think a
> downgrade of libtool would fix it. The libtool folks have done some awful
> things in trying to 'infer' the configuration that it should use that seems
> to have been done only recently. You can also add '--tag=CXX' to the
> SWIG_PY_COMPILE line in Makefile and that might work.
>
> No clue if they plan on fixing their bugs... -- justin
Hello,
I made a patch which will cause that our configure will drive libtool
with --tag=XXX if libtool suppors it. I have a feeling that I am quite
far away from home, so if someone with autoconf+libtool-fu could
review, or test on some not so Gnu/Linuxize machine, that would be nice.
BR, Jani
Log:
Use --tag=XXX for libtool, if it supports it. This should fix these
kind of libtool's warnings:
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
* configure.in
(LIBTOOL,SVN_LIBTOOL): construct same kind of machinery with
experimental-libtool than without (use $(SHELL) in any case).
(sh_libtool): New helper variable, this is runnable from configure
(SVN_LT_CCTAG, SVN_LT_CXXTAG): New substitute variables for
Makefile.in
* Makefile.in
(LTFLAGS): use SVN_LT_CCTAG here
(LTCXXFLAGS): new, use SVN_LT_CXXTAG here
(COMPILE_JAVAHL_CXX) = Use LTCXXFLAGS here, it was LTFLAGS
(LINK_JAVAHL_CXX): ditto
--
Jani Averbach
Re: [PATCH] libtool with --tag=XXX (Was: make swig-py won't compile)
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-01-04 23:42-0800, Justin Erenkrantz wrote:
>
> $(SHELL) is generally only needed if the script isn't executable. It's a
> generally safe assumption that APR will have the executable bit set. However,
> and more importantly, APR comes with a variety of libtool replacements that
> aren't shell scripts, but real C executables. So, a $(SHELL) prefix for them
> would be invalid and wouldn't work.
>
Thanks about clarification!
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libtool with --tag=XXX (Was: make swig-py won't compile)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 04, 2005 at 09:32:01PM -0700, Jani Averbach wrote:
> On 2005-01-04 17:18-0800, Justin Erenkrantz wrote:
> >
> > Looks good. I tweaked it slightly (removed the $(SHELL) part for
> > apr-libtool code path) and committed it in r12591. Thanks! -- justin
> >
> Thanks Justin!
>
> I am not objecting what you did, but would like to know better, so:
>
> AC_PROG_LIBTOOL will expand (at least here) to
> $(SHELL) $(top_builddir)/libtool
> and we are using a same kind of form for SVN_LIBTOOL.
>
> Why don't we use $(SHELL) for apr's libtool? I thought that using an
> explicit shell for it would be a good thing to do, at least because of
> consistency, if not otherwise?
$(SHELL) is generally only needed if the script isn't executable. It's a
generally safe assumption that APR will have the executable bit set. However,
and more importantly, APR comes with a variety of libtool replacements that
aren't shell scripts, but real C executables. So, a $(SHELL) prefix for them
would be invalid and wouldn't work.
FWIW, the experimental libtool option is mainly in place so that I don't have
to use GNU libtool: speeds my builds up by a factor of 2 or more... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libtool with --tag=XXX (Was: make swig-py won't compile)
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-01-04 17:18-0800, Justin Erenkrantz wrote:
>
> Looks good. I tweaked it slightly (removed the $(SHELL) part for
> apr-libtool code path) and committed it in r12591. Thanks! -- justin
>
Thanks Justin!
I am not objecting what you did, but would like to know better, so:
AC_PROG_LIBTOOL will expand (at least here) to
$(SHELL) $(top_builddir)/libtool
and we are using a same kind of form for SVN_LIBTOOL.
Why don't we use $(SHELL) for apr's libtool? I thought that using an
explicit shell for it would be a good thing to do, at least because of
consistency, if not otherwise?
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libtool with --tag=XXX (Was: make swig-py won't
compile)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, January 4, 2005 2:23 PM -0700 Jani Averbach <ja...@jaa.iki.fi>
wrote:
> I made a patch which will cause that our configure will drive libtool
> with --tag=XXX if libtool suppors it. I have a feeling that I am quite
> far away from home, so if someone with autoconf+libtool-fu could
> review, or test on some not so Gnu/Linuxize machine, that would be nice.
Looks good. I tweaked it slightly (removed the $(SHELL) part for
apr-libtool code path) and committed it in r12591. Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org