http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||nightstrike at gmail
--- Comment #7 from kkylheku at gmail dot com 2008-02-23 08:03 ---
Both my patches apply even if Carlos' patches are removed. The crti.o problem
remains.
What's happening is that xgcc actually searches for the crti.o module, and then
passes the full path to crti.o down to collect2 if
--- Comment #8 from kkylheku at gmail dot com 2008-02-23 08:54 ---
I ended up doing the symlink trick because quite a bit of the sysroot material
is needed to build everything, like libstdc++. It worked like a charm. And so
now I have a compiler with search paths only in its own tree.
--- Comment #9 from drow at gcc dot gnu dot org 2008-02-23 17:43 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:03:34AM -, kkylheku at gmail dot
--- Comment #10 from drow at gcc dot gnu dot org 2008-02-23 17:45 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:54:56AM -, kkylheku at gmail
--- Comment #1 from kkylheku at gmail dot com 2008-02-23 01:35 ---
Created an attachment (id=15210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15210action=view)
Patch to gcc/prefix.c for path relocation.
At some point gcc/gcc.c calls the function set_std_prefix in gcc/prefix.c
--- Comment #2 from kkylheku at gmail dot com 2008-02-23 01:40 ---
Created an attachment (id=15211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15211action=view)
Hack to not have /lib and /usr/ paths in cross-compiler.
I don't know whether this path is right in general, but it
--- Comment #3 from kkylheku at gmail dot com 2008-02-23 02:18 ---
Oops, I spoke to soon. The no-prefix-search path breaks my final gcc build,
with shared libraries and glibc. When making libgcc_s.so, it can't find the
crti.o module.
What's happening is two problems.
Firstly, it
--- Comment #4 from drow at gcc dot gnu dot org 2008-02-23 04:38 ---
It's found through multilib os-directory suffixes.
How did you configure GCC?
The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will
conflict. In fact that's another of Carlos's patches. I
--- Comment #5 from kkylheku at gmail dot com 2008-02-23 04:58 ---
(In reply to comment #4)
[crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld being called on a bunch of
--- Comment #6 from kkylheku at gmail dot com 2008-02-23 05:06 ---
(In reply to comment #5)
(In reply to comment #4)
[crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld
12 matches
Mail list logo
