This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin issues with 2.12 (was Re: Branching for 2.12)

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
>>> fine.
>>> 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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]