--- 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.
--
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-04-03
20:45 ---
Ok so the gcc/g++ i build has optimization on by default. The configuration
scripts don't seem to take this into account and the call to CXX for the atomic
check is optimizing away the check i
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-04-03
17:34 ---
After looking back at my 4.2.3 build logs. The above is somewhat incorrect.
In 4.2.3, the pass 2 toolchain build of libstdc++ correctly checked the target
g++ rather than the host and reported that it
bstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
--- Comment #7 from oblivian at users dot sourceforge dot net 2008-04-03
15:07 ---
They re-closed the binutils bug as invalid again and told me to open a new one.
So here's the new one http://sourceware.org/bugzilla/show_bug.cgi?id=6027
We'll see if it gets any mor
--- Comment #6 from oblivian at users dot sourceforge dot net 2008-04-03
03:24 ---
(In reply to comment #5)
Ok, so this is a sysroot bug in binutils that they marked as invalid
http://sourceware.org/bugzilla/show_bug.cgi?id=4966
I guess I would argue that it's not invalid an
--- Comment #5 from oblivian at users dot sourceforge dot net 2008-04-03
01:40 ---
Is this something special in the compiler specs for libc?
I created this test file conftest.c
#include
int testing_lib()
{
printf("hello world!\n");
return 0;
}
And ra
--- Comment #4 from oblivian at users dot sourceforge dot net 2008-04-03
00:12 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
>
I pulled the compiler command that failed, and ra
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-04-02
16:26 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
>
You mean configure with just --with-build-sys
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804
--- 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 R
--- 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
--- 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
--- 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
--- 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/../pre
--- 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
--- 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? :)
&
--- 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
--- 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.
--
--- 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
--- 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 thi
--- 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
--- 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
--- 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
--- 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
>
--- 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.
&
--- 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
--- 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 go
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-03-31
13:06 ---
Ok, I've now recompiled about a million times with multiple sets of configure
flags and cannot get a stage 1 gcc to compile stage 2 ld correctly. I've got
some runs that exhibit the problem o
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-03-25
04:05 ---
I've started over using the 4.3.0 release source files instead of svn and still
have the same problem.
After more checking I've narrowed this down to stage 2 ld-new, collect2 and the
xgcc fr
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i6
31 matches
Mail list logo
