[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Mem
From: |
ro at TechFak dot Uni-Bielefeld dot DE |
Subject: |
[Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted |
Date: |
13 Nov 2008 19:19:20 -0000 |
------- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-13 19:19 -------
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory
exhausted
ebotcazou at gcc dot gnu dot org writes:
> > Unfortunately, the relevant section
> >
> > We recommend the use of GNU binutils 2.14 or later, or the vendor tools
> > (Sun as, Sun ld). Note that your mileage may vary if you use a combination
> > of the GNU tools and the Sun tools: while the combination GNU as + Sun ld
> > should reasonably work, the reverse combination Sun as + GNU ld is known
> > to
> > cause memory corruption at runtime in some cases for C++ programs.
> >
> > is relatively vague.
>
> What's vague exactly?
the last half-sentence about memory corruption: no details, no PR or
whatever.
> > Anyway, the two other cases I tried (GNU as + Sun ld and GNU as + GNU ld)
> > worked resonably well when comparing testsuite results to the Sun as + Sun
> > ld baseline. Only the Sun as + GNU ld case broke in several respects: this
> > PR + ld/7027 + GCC PRs libgomp/38086 and libstdc++/38092.
>
> Yes, it's effectively unsupported, hence my message.
Although the bugs seem to be easily fixed Besides, breakage wide into the
bootstraps seems like a poor way to convey that information ;-)
> > Unfortunately, I need at least one configuration as a baseline for a proper
> > fix for GCC PR bootstrap/33100.
>
> I don't see why, you don't need a baseline for a bootstrap problem.
My change needs to be tested with both Sun ld and GNU ld since the
inclusion of gcc/config/i386/t-crtstuff will become conditional upon a link
test, and I need to test all paths: older/broken Sun ld, new/fixed Sun ld
and GNU ld. And for the GNU ld case (which I've not tried in a long time
if at all) I need a baseline without my change.
Rainer
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7023
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
- [Bug ld/7023] New: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/11
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/11
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, amodra at bigpond dot net dot au, 2008/11/11
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/12
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, amodra at bigpond dot net dot au, 2008/11/12
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ebotcazou at gcc dot gnu dot org, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ebotcazou at gcc dot gnu dot org, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted,
ro at TechFak dot Uni-Bielefeld dot DE <=
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ebotcazou at gcc dot gnu dot org, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/13
- [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted, ro at TechFak dot Uni-Bielefeld dot DE, 2008/11/21