This is the mail archive of the
mailing list for the binutils project.
Re: cygwin issues with 2.12 (was Re: Branching for 2.12)
- From: Christopher Faylor <cgf at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Sat, 9 Feb 2002 21:20:38 -0500
- Subject: Re: cygwin issues with 2.12 (was Re: Branching for 2.12)
- References: <20020129020357.A26642@nevyn.them.org> <20020129155419.GB475@redhat.com> <20020129105652.A7473@nevyn.them.org> <20020129155930.GA641@redhat.com> <20020131121525.A10522@nevyn.them.org> <20020131204314.GA17268@redhat.com> <20020205051928.GA29771@redhat.com> <20020208013744.A30953@nevyn.them.org> <20020210014741.GA17133@redhat.com>
On Sat, Feb 09, 2002 at 08:47:41PM -0500, Christopher Faylor wrote:
>On Fri, Feb 08, 2002 at 01:37:44AM -0500, Daniel Jacobowitz wrote:
>>On Tue, Feb 05, 2002 at 12:19:28AM -0500, Christopher Faylor wrote:
>>> On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
>>> >On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
>>> >>> Windows target (i686-pc-cygwin), linux host. Don't know about mingw.
>>> >>> If you build a cross compiler and try to link gdb, ld will fail, or
>>> >>> at least it does for me.
>>> >>Could you please try to reproduce this, and give me more exact
>>> >>instructions on how to make it bomb?
>>> >Um. Those were adequate instructions for making it bomb "for me".
>>> >I'll rebuild a current CVS and see if it is fixed now.
>>> Ok, I've rebuilt and confirmed that a link of gdb.exe now works.
>>> Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
>>> utilities in winsup/utils seems to fail.
>>> So, it looks like a c++ issue, maybe? I rebuilt the entire toolchain
>>> with a very recent gcc + binutils + ld + gas and the link step failed.
>>> If I attempt to do the final link with an older toolchain, it works
>>> So, it seems like ld or maybe collect2 (?) is the culprit?
>>Maybe I'm just dense. I did a clean build, from a partially-combined
>>tree of CVS head GCC and binutils. I built newlib, winsup, and all the
>>utils (cygcheck.exe etc.). They all linked using the cygwin-targetted
>>assembler and self-built cygwin DLLs.
>>Sorry, but to continue any further I need more information.
>I don't have any to offer, unfortunately. can. Perhaps you could be
>more specific about what information you require?
>Do you want me to send you object files? Stub libraries?
>Just to be clear, I'm doing this all on linux. Your mention of DLLs
>makes me think that you are possibly doing this on Windows although
>that's probably just a terminology problem since you don't normally use
>DLLs in linking.
Nevermind. I guess this has been a false alarm. I just debugged ld
with gdb again and noticed that it was now dying in "new_op". So, I
updated my version of libstdc++.a and rebuilt it. No more SEGVs.
I had previously rebuilt libstdc++.a about a dozen times but I'd
convinced myself it had nothing to do with the problem. Duh.
It's still a little odd, though, that the version of libstdc++.a that I
had caused the trunk version of ld to crash but worked ok with a three
month old version of ld.
So, apologies for the false alarm. Especially since I know you (Dan)
didn't have a cygwin cross build toolchain on your system already...