Patchwork import newer Libtool?

login
register
mail settings
Submitter Ralf Wildenhues
Date Jan. 10, 2011, 7:01 a.m.
Message ID <20110110070111.GC24102@gmx.de>
Download mbox | patch
Permalink /patch/78079/
State New
Headers show

Comments

Ralf Wildenhues - Jan. 10, 2011, 7:01 a.m.
Hello,

I now have patches to import current git Libtool macro and script files
into the GCC tree.  Since Libtool's interpretation of --with-sysroot
does not match GCC's, I disabled that with a followup patch as below.

The patch series has seen some testing, but honestly, it hasn't seen
as much as I have done for my last Libtool update in GCC, and I also
necessarily rely on some feedback from others, because I do not have
the time and resources to do all kinds of testing myself.

The fact that this arrives weeks after the intended deadline doesn't
help either, of course.  So I'd like to apologize for that.

Basically I'm asking for advice/opinions what to do with this.
Apply to a temporary branch and suggest people to test it?  Apply
to trunk, put on my flame suit and hope hell doesn't break loose?
Wait until after branching and backport from trunk to branch after
some testing period?  Ignore this for 4.6 and go for 4.7?

To put things into perspective: this does fix a number of bugs
reported over the last weeks and months, but AFAIK no P1 or P2
regressions.  It should allow to build GCC with LTO (but for
parallel linking to work Automake changes would still be needed).

Aside, if/when this is agreed on, I'd like to apply as three patches;
while it renders the intermediate two commits unstable under
--enable-maintainer-mode and maybe even broken, it does help patch
handling and analysis a lot for me.  (Same as last time basically.)

The patches do not update libgo, but that one should be fairly
straightforward to do.

Oh yes, src patches are still in the works.

Thank you,
Ralf

Update Libtool files from git upstream.

ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* libtool.m4: Sync from git Libtool.
	* ltoptions.m4: Likewise.
	* ltversion.m4: Likewise.
	* lt~obsolete.m4: Likewise.
	* ltmain.sh: Likewise.

[ diff attached ]

Disable _LT_WITH_SYSROOT in libtool.m4.

ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* libtool.m4 (_LT_WITH_SYSROOT): Replace with stub version.




Regenerate files.

libffi/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.
	* include/Makefile.in: Likewise.
	* man/Makefile.in: Likewise.
	* testsuite/Makefile.in: Likewise.

libgomp/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* aclocal.m4: Likewise.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.

boehm-gc/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.
	* include/Makefile.in: Likewise.

zlib/ChangeLog.gcj:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.

libssp/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* aclocal.m4: Likewise.
	* configure: Likewise.

libgfortran/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* aclocal.m4: Likewise.
	* configure: Likewise.

gcc/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libobjc/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libstdc++-v3/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* aclocal.m4: Likewise.
	* configure: Likewise.
	* doc/Makefile.in: Likewise.
	* include/Makefile.in: Likewise.
	* libsupc++/Makefile.in: Likewise.
	* po/Makefile.in: Likewise.
	* python/Makefile.in: Likewise.
	* src/Makefile.in: Likewise.
	* testsuite/Makefile.in: Likewise.

libquadmath/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.

lto-plugin/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* aclocal.m4: Likewise.
	* configure: Likewise.

fixincludes/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure: Regenerate.

libjava/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.
	* gcj/Makefile.in: Likewise.
	* include/Makefile.in: Likewise.
	* testsuite/Makefile.in: Likewise.

libjava/classpath/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.
	* doc/Makefile.in: Likewise.
	* doc/api/Makefile.in: Likewise.
	* examples/Makefile.in: Likewise.
	* external/Makefile.in: Likewise.
	* external/jsr166/Makefile.in: Likewise.
	* external/relaxngDatatype/Makefile.in: Likewise.
	* external/sax/Makefile.in: Likewise.
	* external/w3c_dom/Makefile.in: Likewise.
	* include/Makefile.in: Likewise.
	* lib/Makefile.in: Likewise.
	* native/Makefile.in: Likewise.
	* native/fdlibm/Makefile.in: Likewise.
	* native/jawt/Makefile.in: Likewise.
	* native/jni/Makefile.in: Likewise.
	* native/jni/classpath/Makefile.in: Likewise.
	* native/jni/gconf-peer/Makefile.in: Likewise.
	* native/jni/gstreamer-peer/Makefile.in: Likewise.
	* native/jni/gtk-peer/Makefile.in: Likewise.
	* native/jni/java-io/Makefile.in: Likewise.
	* native/jni/java-lang/Makefile.in: Likewise.
	* native/jni/java-math/Makefile.in: Likewise.
	* native/jni/java-net/Makefile.in: Likewise.
	* native/jni/java-nio/Makefile.in: Likewise.
	* native/jni/java-util/Makefile.in: Likewise.
	* native/jni/midi-alsa/Makefile.in: Likewise.
	* native/jni/midi-dssi/Makefile.in: Likewise.
	* native/jni/native-lib/Makefile.in: Likewise.
	* native/jni/qt-peer/Makefile.in: Likewise.
	* native/jni/xmlj/Makefile.in: Likewise.
	* native/plugin/Makefile.in: Likewise.
	* resource/Makefile.in: Likewise.
	* scripts/Makefile.in: Likewise.
	* tools/Makefile.in: Likewise.

libmudflap/ChangeLog:
2011-01-09  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.

[ diff not shown due to size ]
Paolo Bonzini - Jan. 10, 2011, 8:12 a.m.
On 01/10/2011 08:01 AM, Ralf Wildenhues wrote:
> Basically I'm asking for advice/opinions what to do with this.
> Apply to a temporary branch and suggest people to test it?  Apply
> to trunk, put on my flame suit and hope hell doesn't break loose?
> Wait until after branching and backport from trunk to branch after
> some testing period?

That's too far away.

> To put things into perspective: this does fix a number of bugs
> reported over the last weeks and months, but AFAIK no P1 or P2
> regressions.  It should allow to build GCC with LTO (but for
> parallel linking to work Automake changes would still be needed).

I'll leave it to the RM.  Certainly it sounds like good changes, but can 
you make a list of PRs that are fixed?

Paolo
Richard Guenther - Jan. 10, 2011, 2:55 p.m.
On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 01/10/2011 08:01 AM, Ralf Wildenhues wrote:
>>
>> Basically I'm asking for advice/opinions what to do with this.
>> Apply to a temporary branch and suggest people to test it?  Apply
>> to trunk, put on my flame suit and hope hell doesn't break loose?
>> Wait until after branching and backport from trunk to branch after
>> some testing period?
>
> That's too far away.
>
>> To put things into perspective: this does fix a number of bugs
>> reported over the last weeks and months, but AFAIK no P1 or P2
>> regressions.  It should allow to build GCC with LTO (but for
>> parallel linking to work Automake changes would still be needed).
>
> I'll leave it to the RM.  Certainly it sounds like good changes, but can you
> make a list of PRs that are fixed?

I'd rather have it on trunk immediately.  If we want it at all or not
I have no idea (because I have no idea what the pros are).  If it
doesn't fix a bug for a primary or secondary host/target we definitely
don't want it at this stage (thus wait for 4.7 and do no backporting
either).

Thanks,
Richard.
Paolo Bonzini - Jan. 10, 2011, 3:16 p.m.
On Mon, Jan 10, 2011 at 15:55, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>> On 01/10/2011 08:01 AM, Ralf Wildenhues wrote:
>>>
>>> Basically I'm asking for advice/opinions what to do with this.
>>> Apply to a temporary branch and suggest people to test it?  Apply
>>> to trunk, put on my flame suit and hope hell doesn't break loose?
>>> Wait until after branching and backport from trunk to branch after
>>> some testing period?
>>
>> That's too far away.
>>
>>> To put things into perspective: this does fix a number of bugs
>>> reported over the last weeks and months, but AFAIK no P1 or P2
>>> regressions.  It should allow to build GCC with LTO (but for
>>> parallel linking to work Automake changes would still be needed).
>>
>> I'll leave it to the RM.  Certainly it sounds like good changes, but can you
>> make a list of PRs that are fixed?
>
> I'd rather have it on trunk immediately.  If we want it at all or not
> I have no idea (because I have no idea what the pros are).

The main pro is that allowing to build GCC with LTO "sounds as" if it
would give more exposure/coverage to new features.  But without a list
of PRs from Ralf I cannot really judge either.

Paolo
Richard Guenther - Jan. 10, 2011, 3:24 p.m.
On Mon, Jan 10, 2011 at 4:16 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On Mon, Jan 10, 2011 at 15:55, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>>> On 01/10/2011 08:01 AM, Ralf Wildenhues wrote:
>>>>
>>>> Basically I'm asking for advice/opinions what to do with this.
>>>> Apply to a temporary branch and suggest people to test it?  Apply
>>>> to trunk, put on my flame suit and hope hell doesn't break loose?
>>>> Wait until after branching and backport from trunk to branch after
>>>> some testing period?
>>>
>>> That's too far away.
>>>
>>>> To put things into perspective: this does fix a number of bugs
>>>> reported over the last weeks and months, but AFAIK no P1 or P2
>>>> regressions.  It should allow to build GCC with LTO (but for
>>>> parallel linking to work Automake changes would still be needed).
>>>
>>> I'll leave it to the RM.  Certainly it sounds like good changes, but can you
>>> make a list of PRs that are fixed?
>>
>> I'd rather have it on trunk immediately.  If we want it at all or not
>> I have no idea (because I have no idea what the pros are).
>
> The main pro is that allowing to build GCC with LTO "sounds as" if it
> would give more exposure/coverage to new features.  But without a list
> of PRs from Ralf I cannot really judge either.

Hm, but LTO bootstrap works for me right now.  Or is this about
things like installing a static libgfortran with LTO bytecode (the only
other useful LTO related thing when building GCC)?

Richard.

> Paolo
>
Ralf Wildenhues - Jan. 10, 2011, 6:24 p.m.
* Richard Guenther wrote on Mon, Jan 10, 2011 at 04:24:49PM CET:
> On Mon, Jan 10, 2011 at 4:16 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> > On Mon, Jan 10, 2011 at 15:55, Richard Guenther
> > <richard.guenther@gmail.com> wrote:
> >> On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> >>>
> >>> I'll leave it to the RM.  Certainly it sounds like good changes, but can you
> >>> make a list of PRs that are fixed?
> >>
> >> I'd rather have it on trunk immediately.  If we want it at all or not
> >> I have no idea (because I have no idea what the pros are).
> >
> > The main pro is that allowing to build GCC with LTO "sounds as" if it
> > would give more exposure/coverage to new features.  But without a list
> > of PRs from Ralf I cannot really judge either.
> 
> Hm, but LTO bootstrap works for me right now.  Or is this about
> things like installing a static libgfortran with LTO bytecode (the only
> other useful LTO related thing when building GCC)?

Well, current in-tree libtool will not pass -flto*, -fwhopr*, or
-fuse-linker-plugin through to the linker, when creating a shared
library.  It "works" in the way that the build succeeds, but it
doesn't expose the feature one would like to see.  I must say that
the last time I did a full LTO test with earlier versions of the
patch were a while ago, though.

Most other issues are not even listed as PRs:

- linking/testing/installing on HP-UX should work again
  <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00893.html>,
- no more $LINENO-related spurious diffs in configure scripts,
- cache variables are used throughout the Libtool macros, which will
  hopefully make it easier for users to work around any remaining
  GCC_NO_EXECUTABLES-induced configure failures stemming from those
  macros, see e.g., parts of the discussion in
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174 or these threads
  http://gcc.gnu.org/ml/gcc/2010-12/msg00074.html
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00317.html
- support for Go (exploiting that would be part of a followup patch
  to update Libtool in libgo),
- building on MSYS or Cygwin with tools from the respective other
  w32 system should mostly work (not sure if that is relevant for GCC,
  these issues were all reported to upstream Libtool only).

Cheers,
Ralf

Patch

diff --git a/libtool.m4 b/libtool.m4
index fd79dcf..f111c79 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1213,33 +1213,8 @@  _LT_DECL([], [ECHO], [1], [An echo program that protects backslashes])
 # _LT_WITH_SYSROOT
 # ----------------
 AC_DEFUN([_LT_WITH_SYSROOT],
-[AC_MSG_CHECKING([for sysroot])
-AC_ARG_WITH([sysroot],
-[  --with-sysroot[=DIR] Search for dependent libraries within DIR
-                        (or the compiler's sysroot if not specified).],
-[], [with_sysroot=no])
-
-dnl lt_sysroot will always be passed unquoted.  We quote it here
-dnl in case the user passed a directory name.
+[ # Disabled for now.
 lt_sysroot=
-case ${with_sysroot} in #(
- yes)
-   if test "$GCC" = yes; then
-     lt_sysroot=`$CC --print-sysroot 2>/dev/null`
-   fi
-   ;; #(
- /*)
-   lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
-   ;; #(
- no|'')
-   ;; #(
- *)
-   AC_MSG_RESULT([${with_sysroot}])
-   AC_MSG_ERROR([The sysroot must be an absolute path.])
-   ;;
-esac
-
- AC_MSG_RESULT([${lt_sysroot:-no}])
 _LT_DECL([], [lt_sysroot], [0], [The root where to search for ]dnl
 [dependent libraries, and in which our libraries should be installed.])])