[Bug bootstrap/35752] New: Combined gcc + binutils source tree doesn't bootstrap

[Bug bootstrap/35752] New: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

I combined the current gcc and binutils mainlines into a combined
gcc + binutils source tree. When I tried to bootstrap it on
Linux/ia32 and Linux/Intel64 with shared library enabled, it went
to an infinite loop when as or ld from stage 2 was used. The problem is
ld-new tries to use itself to relink itself when it is invoked
first time. How should gcc and libtool handle it properly? I
think collect-ld should be modified.


-- 
           Summary: Combined gcc + binutils source tree doesn't bootstrap
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2008-03-29 01:47 -------
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01827.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2008-
                   |                            |03/msg01827.html
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2008-03-31 17:44 -------
*** Bug 35451 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oblivian at users dot
                   |                            |sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2008-03-31 17:48 -------
This is introduced by revision 123775:

http://gcc.gnu.org/ml/gcc-cvs/2007-04/msg00387.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
            Summary|Combined gcc + binutils     |[4.3/4.4 Regression]:
                   |source tree doesn't         |Combined gcc + binutils
                   |bootstrap                   |source tree doesn't
                   |                            |bootstrap


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #4 from bonzini at gnu dot org  2008-03-31 17:53 -------
Patch seems fine, but before approving it I would like a description of why
"tries to [...] relink itself" (important part is *re*link itself), and that
description should also go in exec-tool.in.

Thanks!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2008-03-31 18:16 -------
(In reply to comment #4)
> Patch seems fine, but before approving it I would like a description of why
> "tries to [...] relink itself" (important part is *re*link itself), and that
> description should also go in exec-tool.in.
> 

I am not a libtool person. My best understanding is when shared library
is enabled, libtool will create a shell script, ld-new, and the real
executable as .libs/ld-new.  But .libs/ld-new isn't suitable to be
used in place directly. When the ld-new shell script is run the first
time, it will relink a new real linker, .libs/lt-ld-new, and use
.libs/lt-ld-new instead of .libs/ld-new. I hope libtool person can
provide a real explanation in exec-tool.in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #6 from oblivian at users dot sourceforge dot net  2008-03-31 20:29 -------
Hi guys, I'm moving over from 35451 since it was marked as a duplicate and
marked as resolved.  I'm glad I'm not nuts and this is a problem someone else
has, but... 

I've got a problem with the definition of this bug and the "fix" as it relates
to my problem.  Please note that I can bootstrap 4.3 just fine and it works as
long as the libraries it's building against are in the root directory (e.g.
/lib /usr/lib).  It fails when it tries to bootstrap against the new glibc in
/tools/lib.

I'll try the patch and let you know if it worked in about 4 hours.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[rwild at gcc dot gnu dot org]

------- Comment #7 from rwild at gcc dot gnu dot org  2008-03-31 22:26 -------
While I still haven't had a chance to look at this, here's what I can gather
from the comments or say about libtool:

First, when to-be-installed programs are created using libtool, and they link
against uninstalled libtool libraries, then typically, a binary usable in the
build tree may not be usable in the install tree and vice versa.  Consequently,
there are two of them, plus a wrapper script or binary.  libtool now has two
modes, fast-install and not, to prefer one-shot builds (where, if possible,
the to-be-installed one is built by default, in .libs/$name, and upon execution
of $name, an uninstalled binary is created in .libs/lt-$name).

The fact that ld/Makefile.am contains
  noinst_PROGRAMS = ld-new

(and thus can be construed to not ever be installed) is not passed from
automake
to libtool.  And in this case, ld-new *is* installed, by install-exec-local, so
passing -no-install to libtool would be wrong for some systems.

You should be able to prioritise the creation of the uninstalled binary with
  ld_new_LDFLAGS = -no-fast-install

but note that then, upon 'make install' a relink may be performed by libtool.
I'm not sure whether that would be a better solution than the patch from
comment #1 (and I have yet to try it myself).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #8 from oblivian at users dot sourceforge dot net  2008-03-31 23:09 -------
I am convinced that the patch is almost certainly wrong, is not the root cause
of the problem, and the 4.3.0 implementation of libtool is almost certainly
broken.

While the patch allows the compiler to be built in phase 2 and complete, it is
pulling in libraries from the host system.  4.2.3 Most certainly did not.  I'm
looking at build logs from both versions and for example the 4.2.3 build
configure log for phase 2 showed that it could not find libflex -lfl for all
stages of the build, where as 4.3.0 can't find -lfl in stage 1 and in stage 2
and follow it all of a sudden starts finds it.  Since flex is not installed
until after the phase 2 toolchain it should not be found by the compiler if it
is searching /tools/lib for the whole bootstrap build.

Beyond this bfd in stage 2 of the phase 2 compiler is showing
sys_lib_search_path_spec with /lib and /usr/lib in it, which is very bad for
the phase 2 compiler I'm trying to build.

I'm going to start looking into where sys_lib_search_path_spec is set and find
the deltas between the two versions since I'm not sure where else to look.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #9 from oblivian at users dot sourceforge dot net  2008-03-31 23:25 -------
(In reply to comment #8)
> I'm going to start looking into where sys_lib_search_path_spec is set and find
> the deltas between the two versions since I'm not sure where else to look.
> 

So looking at the delta between the two libtool files in stage 1 and stage 2
bfd shows:

-sys_lib_search_path_spec="/media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/
usr/lib/gcc/i686-pc-linux-gnu/4.3.0
/media/disk-3/tools-006eaa66298e39accdc34d3c
a2530559/usr/lib/gcc
/media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/usr/i6
86-pc-linux-gnu/lib
/media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/usr/lib
 /lib /usr/lib"
+sys_lib_search_path_spec="/media/disk-3/build/scripts/tools/toolchain-pass-2/bu
ild/prev-gcc /tools-006eaa66298e39accdc34d3ca2530559/usr/i686-pc-linux-gnu/bin
/
lib /usr/lib"

The - is the stage 1 bfd build directory and + is the stage 2 bfd.  Libtool is
not including the tools library directories in stage 2.

Please ignore the uuid I use to differentiate tools directories since they are
symlinked to the host system's root directory.

Note this is currently with the exec-tools.in patch applied.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #10 from bonzini at gnu dot org  2008-04-01 07:08 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap

hjl dot tools at gmail dot com wrote:
> ------- Comment #5 from hjl dot tools at gmail dot com  2008-03-31 18:16 -------
> (In reply to comment #4)
>> Patch seems fine, but before approving it I would like a description of why
>> "tries to [...] relink itself" (important part is *re*link itself), and that
>> description should also go in exec-tool.in.
>>
> 
> I am not a libtool person. My best understanding is when shared library
> is enabled, libtool will create a shell script, ld-new, and the real
> executable as .libs/ld-new.  But .libs/ld-new isn't suitable to be
> used in place directly. When the ld-new shell script is run the first
> time, it will relink a new real linker, .libs/lt-ld-new, and use
> .libs/lt-ld-new instead of .libs/ld-new. I hope libtool person can
> provide a real explanation in exec-tool.in.

Ah, right, now I remember seeing this behavior too.  If you wish to 
explore Ralf's proposed usage of -no-fast-install, I would prefer that 
but I cannot approve that patch (which would have to go to the binutils 
maintainers).

Otherwise, please add a comment like this:

# When ld-new is first executed from the build tree, libtool
# will relink it as .libs/lt-ld-new, so that it can give it
# an RPATH that refers to the build tree.  While doing this
# we need to use the previous-stage linker, or we have an infinite
# loop.

and commit the patch.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #11 from oblivian at users dot sourceforge dot net  2008-04-01 10:24 -------
(In reply to comment #10)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap
> # When ld-new is first executed from the build tree, libtool
> # will relink it as .libs/lt-ld-new, so that it can give it
> # an RPATH that refers to the build tree.  While doing this
> # we need to use the previous-stage linker, or we have an infinite
> # loop.

That doesn't make sense from what I'm seeing, so either I need to reopen the
bug that I submitted or we are headed down the wrong path.

The stage 1 ld works as far as linking the stage 1 gcc which is directly after
it.  It's only when we get to stage 2 that things break.  If the above were
true, I would not be able to get to stage 2 since the stage 1 ld would have to
use the host ld to link itself and from the logs I have...

>From stage 1 gcc configure output:
checking what linker to use... newly built ld
And gcc stage 1 compiles and links.

Beyond this, I will reiterate that I can do a complete bootstrap of the 4.3.0
compiler in phase 1, without this patch, and it completes building all stages
and works.  The compiler in phase 2 of the build, when linking against
libraries not in the root /lib and /usr/lib directories is what is confusing
the stage 2 programs and not allowing it to work.

It appears after more searching that binutils configure scripts are trying to
pull the sys_lib_search_path_spec variable from the stage 1 xgcc for all stage
2 programs, and that stage 1 gcc is building and linking against correct
library paths, but not incorporating those paths into it's output for
-print-search-dirs.  Since it doesn't have these paths correctly
sys_lib_search_path_spec is set incorrectly by stage 2 configure in ld and
libtool gets generated with incorrect library paths thus infecting itself with
the host libraries and causing havoc to ensue with the build.

So to summarize what I see:

Stage 1 ld is built against /tools/lib libraries
Stage 1 gcc is built against /tools/lib libraries, but doesn't output these
paths with -print-search-dirs
Stage 2 ld is build using mixed paths from stage 1 gcc and the environment and
tries to link against /lib libraries which apparently causes it to go nuts
since everything it is built with is trying for /tools/lib or the recursive
loop is libtool flip flopping between linking to /lib then to /tools/lib
without making up it's mind.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #12 from bonzini at gnu dot org  2008-04-01 11:21 -------
I think there are two bugs.  One is the infinite loop, and H.J.'s patch is
"masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
"masking" in ld/Makefile.am).  The other is yours, which does not have anything
to do with the infinite loop AFAICS.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #13 from oblivian at users dot sourceforge dot net  2008-04-01 11:51 -------
(In reply to comment #12)
> I think there are two bugs.  One is the infinite loop, and H.J.'s patch is
> "masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
> "masking" in ld/Makefile.am).  The other is yours, which does not have anything
> to do with the infinite loop AFAICS.
> 
I too have an infinite loop at stage 2 "gcc" which is the linker calling itself
recursively, but as you can see from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451, I've been tracing the route
of the problem.  I agree that the patch is "masking" the problem, but I still
think it's a change to gcc that is causing binutils breakage.  This may need to
be fixed in binutils, but right now I need to figure out what changed in gcc.

I did forget to mention the following last night as well...
I ran a bootstrap with H.J's patch and it compiles through, but is pulling host
libraries.
I also ran a profiledbootstrap with H.J.'s patch and it can't find newer gcov_
symbols since it appears to no longer be linking with the latest 4.3.0
libraries and trying against older 4.1.2 gcc libraries.

After some stuff I've done this morning, I think it is most definitely related
to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 and the search path
cleanup on the 4.3.0 branch.  I applied the patch as a test, and now I get a
/tools/usr/lib directory in the sys_lib_search_path_dirs of my binutils libtool
files BEFORE the standard /lib /usr/lib.  I think to fix both problems someone
needs to describe the "correct" way of providing the retargeted search paths to
the binutils configure scripts for stage 2 and beyond.  And sysroot is just
broken for this at this point, I went through multiple iterations of sysroot
trials with no success.

I tried adding BOOT_LDFLAGS=-B/tools/usr/lib -B/tools/lib to and passing
BOOT_CFLAGS with the same as well and they don't make it to the binutils
program configure scripts.

Any insight is appreciated.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #14 from bonzini at gnu dot org  2008-04-01 11:54 -------
hm, I see now.  H.J. hold on.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #15 from oblivian at users dot sourceforge dot net  2008-04-01 11:57 -------
In fact the more I think about it, the search path clean up is what has
definitely got to be killing this build.  The binutils configure scripts rely
on the retargeted search paths to come from the previous stage gcc, which have
now been removed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #16 from bonzini at gnu dot org  2008-04-01 12:08 -------
> The stage 1 ld works as far as linking the stage 1 gcc which is directly after
> it.  It's only when we get to stage 2 that things break. 

This is a red herring.  stage 1 ld goes through the same relink process, but it
uses the host ld to do that (no problem).  stage 2 ld adds a further
indirection through stage 1's gcc/collect-ld, which is a small script to
discern between when to use prev-ld/ld-new and when to use ld/ld-new; the
presence of a shell script as ld/ld-new, and the fact that the script *uses ld
itself*, is what confuses the gcc/collect-ld script.

So H.J.'s patch in some sense is right, because it fixes the "buggy" script. 
The reason I'd prefer ld to be patched is that H.J.'s fix is a tad brittle and
susceptible to changes in libtool; avoiding the one-time relinking is simpler. 
But OTOH, until the patched ld/Makefile.am goes into a released version there
is no way to bootstrap a gcc+binutils tree. :-(  I'll make up my mind soon.

Anyway, any other problem you have regarding search paths, as I said, a second
bug, and one that should not cause any kind of infinite loop.  We have to fix
that one too, of course, but let's sort out this one first, please.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-04-01 12:08:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #17 from oblivian at users dot sourceforge dot net  2008-04-01 12:14 -------
I understand the difference now, and thanks.

Still not sure why I can make it through the whole host bootstrap phase without
his patch though.  Maybe a 4.4 specific change issue?

Let me know if you open a second bug on my issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #18 from bonzini at gnu dot org  2008-04-01 12:33 -------
Created an attachment (id=15402)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view)
my version of H.J.'s patch

I think this is the right way to do it, more or less.

Can anyone test it?  (I don't have binutils checked out right now...)

You have to run autoconf too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #19 from oblivian at users dot sourceforge dot net  2008-04-01 12:40 -------
(In reply to comment #18)
> Created an attachment (id=15402)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view) [edit]
> my version of H.J.'s patch
> 
> I think this is the right way to do it, more or less.
> 
> Can anyone test it?  (I don't have binutils checked out right now...)
> 
> You have to run autoconf too.
> 
Yeah I'll apply it now, hold on for about 4 hours.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #20 from bonzini at gnu dot org  2008-04-01 13:49 -------
if it reaches the end of ld compilation in stage2, that's already enough.  (and
less than 4 hours).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #21 from oblivian at users dot sourceforge dot net  2008-04-01 13:53 -------
(In reply to comment #20)
> if it reaches the end of ld compilation in stage2, that's already enough.  (and
> less than 4 hours).
> 

Sorry, but for me to test it I have to wait until the pass 2 compiler, since
that's the one that breaks.  So I can at least tell you it didn't break the
pass 1 compiler in < 4 hours.  Of course I've already had to restart the build
5 times to get my scripts to run autoconf in the gcc subdirectory so we'll see
how long it takes to get through pass 1 (i just restarted the build hopefully
for the last time).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #22 from oblivian at users dot sourceforge dot net  2008-04-01 15:30 -------
Doesn't work.  In my setup enable-fast-install is not getting set, but the
prev-ld is generating an lt-ld-new, so it assumes it should use the current ld
instead of the prev-ld binary.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #23 from bonzini at gnu dot org  2008-04-01 15:36 -------
and if you modify collect-ld manually to set it to yes?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #24 from oblivian at users dot sourceforge dot net  2008-04-01 15:39 -------
(In reply to comment #23)
> and if you modify collect-ld manually to set it to yes?
> 
Sure that works, but doesn't that defeat the purpose? :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #27 from bonzini at gnu dot org  2008-04-01 15:42 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap

oblivian at users dot sourceforge dot net wrote:
> ------- Comment #24 from oblivian at users dot sourceforge dot net  2008-04-01 15:39 -------
> (In reply to comment #23)
>> and if you modify collect-ld manually to set it to yes?
>>
> Sure that works, but doesn't that defeat the purpose? :)

Gives me enough context to commit a patch that actually works.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #25 from oblivian at users dot sourceforge dot net  2008-04-01 15:41 -------
(In reply to comment #24)
> (In reply to comment #23)
> > and if you modify collect-ld manually to set it to yes?
> > 
> Sure that works, but doesn't that defeat the purpose? :)
> 
How about changing it to != no?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[Ralf dot Wildenhues at gmx dot de]

------- Comment #26 from Ralf dot Wildenhues at gmx dot de  2008-04-01 15:42 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
        binutils source tree doesn't bootstrap

* bonzini at gnu dot org wrote on Tue, Apr 01, 2008 at 05:36:52PM CEST:
> ------- Comment #23 from bonzini at gnu dot org  2008-04-01 15:36 -------
> and if you modify collect-ld manually to set it to yes?

fast-install cannot work on all systems, and does not work on some where
it could be made to.  What I suggesteded was to use -no-fast-install:
you do not want the relink to happen for the execution of the
uninstalled program.

Sorry, I cannot look into this until later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #28 from hjl dot tools at gmail dot com  2008-04-01 15:49 -------
Created an attachment (id=15408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408&action=view)
A setup for combined gcc/binutils source tree

This is the setup to create a combined gcc/binutils source tree. You
can use it to verify if bootstrap works.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

------- Comment #29 from hjl dot tools at gmail dot com  2008-04-01 15:50 -------
(In reply to comment #27)
> 
> Gives me enough context to commit a patch that actually works.
> 
> Paolo
> 

Please get

http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408

and create a combined gcc/binutils source tree to verify your patch. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

------- Comment #30 from bonzini at gnu dot org  2008-04-01 16:11 -------
Created an attachment (id=15409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view)
new patch

@Ralf: yes, I understood that (I just wanted to understand if the failure was
just that my way of setting enable_fast_install was too hacky).

This patch should work.  It creates a good collect-ld for me.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15402|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #31 from oblivian at users dot sourceforge dot net  2008-04-01 16:44 -------
(In reply to comment #30)
> Created an attachment (id=15409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view) [edit]
> new patch
> 
> @Ralf: yes, I understood that (I just wanted to understand if the failure was
> just that my way of setting enable_fast_install was too hacky).
> 
> This patch should work.  It creates a good collect-ld for me.
> 

Nope

/build/scripts/tools/toolchain-pass-2/build/gcc/../prev-binutils/nm-new: cannot
execute: No such file or directory
No symbols seen -- broken or mis-installed nm?

This was in libgcc before the stage 1 directories are moved to prev-<app>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #32 from oblivian at users dot sourceforge dot net  2008-04-01 18:55 -------
(In reply to comment #30)
> This patch should work.  It creates a good collect-ld for me.
> 

How about a simple change without the whole fast-install patch.

    if test -x $scriptdir/../prev-$dir/$prog; then
      exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
    else
      exec $scriptdir/../$dir/$prog ${1+"$@"}
    fi

Thats it.  Just prefer the use of the previous stage utilities. No worrying
about the state of the current stage utilities.  Unless I'm missing something
(e.g. internal gcc reasons) doesn't this meet the primary requirement
bootstrapping the compiler (i.e. building the current stage with the previous)
and prevents mixing partially finished utilities inside the stage?
It also keeps the exec-tool.in script clean from specialized code depending on
the target it's being run as (well except for the invoke case statement at the
top).

I'm currently through stage 2 with this simple change to exec-tool.in.

As long as this doesn't break any rules, it should allow the sysroot problems I
had to disappear as well, which will fix my prefix issue as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #33 from oblivian at users dot sourceforge dot net  2008-04-01 19:04 -------
(In reply to comment #32)
> (In reply to comment #30)
> > This patch should work.  It creates a good collect-ld for me.
> > 
> 
> How about a simple change without the whole fast-install patch.
>
How about not, since intl configure now gives me this:
xgcc: ldgram.o: No such file or directory
xgcc: ldlex.o: No such file or directory
xgcc: lexsup.o: No such file or directory
xgcc: ldlang.o: No such file or directory
xgcc: mri.o: No such file or directory
xgcc: ldctor.o: No such file or directory
xgcc: ldmain.o: No such file or directory
xgcc: ldwrite.o: No such file or directory
xgcc: ldexp.o: No such file or directory
xgcc: ldemul.o: No such file or directory
xgcc: ldver.o: No such file or directory
xgcc: ldmisc.o: No such file or directory
xgcc: ldfile.o: No such file or directory
xgcc: ldcref.o: No such file or directory
xgcc: sha1.o: No such file or directory
xgcc: eelf_i386.o: No such file or directory
xgcc: ei386linux.o: No such file or directory
xgcc: ../bfd/.libs/libbfd.so: No such file or directory
xgcc: ../libiberty/libiberty.a: No such file or directory

Oh well. I thought it would work


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

------- Comment #34 from oblivian at users dot sourceforge dot net  2008-04-01 19:04 -------
Sorry make that stage 3 intl gives me the above


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #35 from bonzini at gnu dot org  2008-04-02 10:08 -------
the infinite loop is fixed, don't know if the second bug remains.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gcc dot gnu dot org]

------- Comment #36 from bonzini at gnu dot org  2008-04-02 10:08 -------
Subject: Bug 35752

Author: bonzini
Date: Wed Apr  2 10:07:58 2008
New Revision: 133832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133832
Log:
2008-04-02  Paolo Bonzini  <bonzini@gnu.org>

        PR bootstrap/35752
        * Makefile.in (objdir): Set it here.
        * configure.ac: Not here.  Find dynamic linker characteristics.
        * exec-tool.in: Use them.
        * aclocal.m4: Regenerate.
        * configure: Regenerate.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/aclocal.m4
    trunk/gcc/configure
    trunk/gcc/configure.ac
    trunk/gcc/exec-tool.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

------- Comment #37 from oblivian at users dot sourceforge dot net  2008-04-02 13:47 -------
(In reply to comment #35)
> the infinite loop is fixed, don't know if the second bug remains.
> 
Yes and no, It fixes the compilation so that ld no longer gets into a loop, but
the installed compiler is still not working due to the missing search paths.

This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
explored the issue of using sysroot for native builds and it appears the
consensus is not to support retargeted compilers anymore for native builds, and
that the sysroot framework should be used even though some people are still
stating that it is for cross compiling only.

I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
at least I can't find a bug on it in gcc bugzilla).

Thanks for all the help.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #38 from bonzini at gnu dot org  2008-04-02 13:59 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
> appears no one has tried a combined gcc + binutils bootstrap with sysroot (or
> at least I can't find a bug on it in gcc bugzilla).

Ok, CC me on that bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

------- Comment #39 from oblivian at users dot sourceforge dot net  2008-04-02 14:19 -------
Created an attachment (id=15413)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15413&action=view)
Optional way to fix ld relink problems

Just for completeness, here is the fix the Ralf was suggesting.  I tried this
out and it seems to work as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #40 from hjl dot tools at gmail dot com  2008-04-21 13:36 -------
The fix

      test -f $lt_prog-recursive && exec $scriptdir/../prev-$dir/$prog
${1+"$@"}

      touch $lt_prog-recursive
      $scriptdir/../$dir/$prog ${1+"$@"}
      result=$?
      rm -f $lt_prog-recursive
      exit $result

is parallel build safe. When as is invoked, it creates a $lt_prog-recursive.
Before it finishes, another as is invoked and detects $lt_prog-recursive
exist. Error.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joey dot ye at intel dot com
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #41 from bonzini at gnu dot org  2008-04-21 13:53 -------
Ralf, do you think it would be possible to create the script atomically in
ltmain.sh?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #42 from hjl dot tools at gmail dot com  2008-04-21 14:01 -------
I think my original patch

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01827.html

is the simplest one since it calls the linker, the only tool which
suffers this bug, from previous stage only in linker directory which
is the only place where this problem exists.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #43 from bonzini at gnu dot org  2008-04-21 14:07 -------
Yes, but your patch is, even if not wrong, unsatisfactory.  Even though only
one program suffers from this bug now, it is in general a problem that libtool
invokes some of the tools that are being built, and I want to fix it in a
general way.  You are fixing a symptom, but it is much better to fix the cause.

I think this is now a bug in libtool, and fixing it will benefit upstream too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

------- Comment #44 from Ralf dot Wildenhues at gmx dot de  2008-04-21 14:13 -------
It is probably possible to generate the wrapper script atomically.
But this solution can become ugly: on w32 we may generate also a wrapper
executable.

I still don't see a convincing argument why you don't use -no-fast-install.
If the problem is that you don't like the relink to happen at 'make install'
time, then why don't you generate two 'ld' programs, one for installation
and one for use uninstalled, with -no-fast-install, or even -no-install.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #45 from hjl dot tools at gmail dot com  2008-04-21 14:26 -------
(In reply to comment #43)
> Yes, but your patch is, even if not wrong, unsatisfactory.  Even though only
> one program suffers from this bug now, it is in general a problem that libtool
> invokes some of the tools that are being built, and I want to fix it in a
> general way.  You are fixing a symptom, but it is much better to fix the cause.
> 
> I think this is now a bug in libtool, and fixing it will benefit upstream too.
> 

But this is a very unique relink and linker problem. It can only happen
to linker. Why make a simple problem more complicated than necessary?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #46 from bonzini at gnu dot org  2008-04-21 14:38 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> But this is a very unique relink and linker problem. It can only happen
> to linker. Why make a simple problem more complicated than necessary?

First, the linker may in principle call again the assembler (LTO); the 
libtool wrapper calls gcc, not ld.

Second, even if we went with your patch the race in libtool ought to be 
analyzed (and IMO fixed but Ralf may convince me otherwise).

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #47 from bonzini at gnu dot org  2008-04-21 14:39 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> It is probably possible to generate the wrapper script atomically.
> But this solution can become ugly: on w32 we may generate also a wrapper
> executable.

For win32 it suffices to:

1) create wrapper executable under random name
2) create wrapper script under random name
3) move wrapper script to correct name
4) move wrapper executable to correct name

If you invert 1 and 2, the patch is a mess because you have to move 
around a lot of code. :-)  If you invert 3 and 4, the executable may 
fail because of not finding a script -- this is actually another problem 
with the current code.

(BTW, were you libtool maintainers aware of this race/these races?)

> I still don't see a convincing argument why you don't use -no-fast-install.
> If the problem is that you don't like the relink to happen at 'make install'
> time, then why don't you generate two 'ld' programs, one for installation
> and one for use uninstalled, with -no-fast-install, or even -no-install.

The problem is that you want to make a combined tree with released gcc 
and binutils, and since this is arguably a gcc bug you want the latest 
gcc without the bug to compile a combined tree with any released 
binutils version.

At worse, we could just pass --disable-fast-install in the toplevel 
configure when gcc is present.  That could be a solution for 4.3 actually.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #48 from hjl dot tools at gmail dot com  2008-04-21 15:52 -------
(In reply to comment #46)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> 
> > But this is a very unique relink and linker problem. It can only happen
> > to linker. Why make a simple problem more complicated than necessary?
> 
> First, the linker may in principle call again the assembler (LTO); the 
> libtool wrapper calls gcc, not ld.
> 

I don't think it is a problem since this problem is limited to that the
new linker is used to relink itself, which leads to a infinite recursive
loop.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2008-04-01 12:08:52         |2008-04-21 15:52:43
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #49 from bonzini at gnu dot org  2008-04-21 16:05 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I don't think it is a problem since this problem is limited to that the
> new linker is used to relink itself, which leads to a infinite recursive
> loop.

The same thing could happen when the new assembler is relinked itself, 
if the relink was actually an LTO pass (at the end you assemble the 
result of whole-program optimization, and reach an infinite loop).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #50 from hjl dot tools at gmail dot com  2008-04-21 16:18 -------
(In reply to comment #49)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> 
> > I don't think it is a problem since this problem is limited to that the
> > new linker is used to relink itself, which leads to a infinite recursive
> > loop.
> 
> The same thing could happen when the new assembler is relinked itself, 
> if the relink was actually an LTO pass (at the end you assemble the 
> result of whole-program optimization, and reach an infinite loop).
> 

The sequence for LTO will be

1. Gcc calls ld for LTO.
2. ld calls as to assemble assembly code.
3. as calls ld to relink itself.
   3.1 ld calls the previous linker to relink itself to create lt-ld.
   3.2 lt-ld is used to relink as to create lt-as
   3.3 lt-as is used to assemble assembly code.
4. lt-ld is used to finish LTO.

Will LTO be applied on the fully linked linker in step 3.1? If yes, can we
disable LTO for step 3.1?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #51 from bonzini at gnu dot org  2008-04-21 16:25 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared

> 3. as calls ld to relink itself.
>    3.1 ld calls the previous linker to relink itself to create lt-ld.
> 
> Will LTO be applied on the fully linked linker in step 3.1?

I think yes, unless libtool is modified to invoke ld directly for the 
relink step.

> If yes, can we disable LTO for step 3.1?

I think no but anyway that would be hack after hack. :-(

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[hjl dot tools at gmail dot com]

------- Comment #52 from hjl dot tools at gmail dot com  2008-04-21 16:40 -------
(In reply to comment #51)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap with --enable-shared
> 
> > 3. as calls ld to relink itself.
> >    3.1 ld calls the previous linker to relink itself to create lt-ld.
> > 
> > Will LTO be applied on the fully linked linker in step 3.1?
> 
> I think yes, unless libtool is modified to invoke ld directly for the 
> relink step.
> 

I can extend my patch to as.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #53 from bonzini at gnu dot org  2008-04-21 17:02 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


> I can extend my patch to as.

You surely can (and actually extend it to everything else that is 
invoked via exec-tool)...  but then you're never using the bootstrapped 
tools in a 2-stage bootstrap!  In a 3-stage bootstrap you will because 
you'll invoke stage2 tools, and stage2 must be the same as stage3.  But 
this would be very confusing for people debugging, and in the worst 
(very hypothetical, I admit) case, it could even cause comparison 
failures if the stage1 tools are wrong in some way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

------- Comment #54 from Ralf dot Wildenhues at gmx dot de  2008-04-22 05:27 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
        binutils source tree doesn't bootstrap with --enable-shared

* bonzini at gnu dot org wrote on Mon, Apr 21, 2008 at 04:39:20PM CEST:
> For win32 it suffices to:
> 
> 1) create wrapper executable under random name
> 2) create wrapper script under random name
> 3) move wrapper script to correct name
> 4) move wrapper executable to correct name

Probably.  Libtool 2.2.2 has things changed there, and a couple of
issues still, so I need to look at this anyway.

> (BTW, were you libtool maintainers aware of this race/these races?)

I wasn't.  But I don't think we guarantee atomic creation of output.
Take the trivial case: program needs no relink.  In that case, it's
up to the compiler/linker whether the program is created atomically.
GCC doesn't do it.  :-)

So I'm not yet convinced this particular race to be a Libtool bug.

> The problem is that you want to make a combined tree with released gcc 
> and binutils, and since this is arguably a gcc bug you want the latest 
> gcc without the bug to compile a combined tree with any released 
> binutils version.

Ah ok.

> At worse, we could just pass --disable-fast-install in the toplevel 
> configure when gcc is present.  That could be a solution for 4.3 actually.

But then you may not strictly install ld-new, as it may not work on some
systems.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #55 from bonzini at gnu dot org  2008-04-22 06:27 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap with --enable-shared


>> (BTW, were you libtool maintainers aware of this race/these races?)
> 
> I wasn't.  But I don't think we guarantee atomic creation of output.
> Take the trivial case: program needs no relink.  In that case, it's
> up to the compiler/linker whether the program is created atomically.
> GCC doesn't do it.  :-)
> 
> So I'm not yet convinced this particular race to be a Libtool bug.

... but you can assume it "is created once and for all" after it is 
built (something you can guarantee with Makefile rules).  That's an 
invariant that libtool's relinking breaks, and that atomic operation 
would restore.

Another possibility would be to force libtool to relink at linking time, 
i.e. keep the fast install, but do the relinking even before the program 
is invoked (and the wrapper script installed).  But I assume it is a mess?

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[Ralf dot Wildenhues at gmx dot de]

------- Comment #56 from Ralf dot Wildenhues at gmx dot de  2008-04-22 17:51 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
        binutils source tree doesn't bootstrap with --enable-shared

* bonzini at gnu dot org wrote on Tue, Apr 22, 2008 at 08:27:07AM CEST:
> > So I'm not yet convinced this particular race to be a Libtool bug.
> 
> ... but you can assume it "is created once and for all" after it is 
> built (something you can guarantee with Makefile rules).  That's an 
> invariant that libtool's relinking breaks, and that atomic operation 
> would restore.

OK, I understood the issue now.  I'll fix Libtool.  Thanks for
explaining, and persevering.

> Another possibility would be to force libtool to relink at linking time, 
> i.e. keep the fast install, but do the relinking even before the program 
> is invoked (and the wrapper script installed).  But I assume it is a mess?

Yes, that sounds like a mess.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[oblivian at users dot sourceforge dot net]

------- Comment #57 from oblivian at users dot sourceforge dot net  2008-04-25 15:00 -------
I don't have permissions to change the status, but it looks like bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503 is a dup or at least related
if someone wants to clean it up.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #58 from bonzini at gnu dot org  2008-04-25 15:21 -------
*** Bug 33503 has been marked as a duplicate of this bug. ***


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |s_pyptev at ipmce dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #59 from bonzini at gnu dot org  2008-07-31 12:44 -------
Should be fixed by the patch at

http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/8574

which is waiting to be applied upstream.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #60 from bonzini at gnu dot org  2008-08-01 08:26 -------
There is no need for additional patches: a trunk bootstrap is now building gcc
stage2, so it's fixed there.  I'll backport to 4.3 the patch from comment #36.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
   Last reconfirmed|2008-04-21 15:52:43         |2008-08-01 08:26:06
               date|                            |
            Summary|[4.3/4.4 Regression]:       |[4.3 Regression]: Combined
                   |Combined gcc + binutils     |gcc + binutils source tree
                   |source tree doesn't         |doesn't bootstrap with --
                   |bootstrap with --enable-    |enable-shared
                   |shared                      |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gcc dot gnu dot org]

------- Comment #61 from bonzini at gnu dot org  2008-08-01 09:52 -------
Subject: Bug 35752

Author: bonzini
Date: Fri Aug  1 09:51:03 2008
New Revision: 138504

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138504
Log:
2008-08-01  Paolo Bonzini  <bonzini@gnu.org>

        PR bootstrap/35752
        * Makefile.in (objdir): Set it here.
        * configure.ac: Not here.  Find dynamic linker characteristics.
        * exec-tool.in: Use them.
        * aclocal.m4: Regenerate.
        * configure: Regenerate.


Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/Makefile.in
    branches/gcc-4_3-branch/gcc/aclocal.m4
    branches/gcc-4_3-branch/gcc/configure
    branches/gcc-4_3-branch/gcc/configure.ac
    branches/gcc-4_3-branch/gcc/exec-tool.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

------- Comment #62 from bonzini at gnu dot org  2008-08-04 12:24 -------
committed.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752