libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Libtool stresstest.at segfault on Cygwin/MinGW


From: Peter Ekberg
Subject: RE: Libtool stresstest.at segfault on Cygwin/MinGW
Date: Thu, 29 Sep 2005 15:10:34 +0200
User-agent: Mutt/1.5.10i

* Peter Ekberg wrote on Thursday, September 22, 2005 09:45 CEST:
> * Ralf Wildenhues wrote on Wednesday, September 21, 2005 22:37 CEST:
> > Hi Peter,
> > 
> > * Peter Ekberg wrote on Mon, Sep 19, 2005 at 09:05:04PM CEST:
> > > Ralf Wildenhues wrote on Monday, September 19, 2005 17:10 CEST
> > > > * Peter Ekberg wrote on Mon, Sep 19, 2005 at 04:17:56PM CEST:
> > 
> > > > > Well, the test segfaults on MinGW with the patch, and if I add
> > > > > DATA to all symbols manually in asyms the (reordered) test goes
> > > > > on until the same problem is triggered when export_symbols_cmds
> > > > > is invoked because of the -export-symbols-regex option, so I
> > > > > assume it is not good enough for MinGW. I think the import lib
> > > > > gets screwed up if data symbols are not correctly tagged.
> > > > 
> > > > OK.  I assume it's not a linker bug then.
> > > 
> > > (nit: s/linker/compiler/ I suppose)
> > 
> > Well, I guess our current best bet is `nm', right?  ;-)
> 
> Not really, nm does as it documents. These data symbols really
> are in the .text segment so T is not wrong. I still blame the
> compiler for putting them there in the first place...

An update, I asked the MinGW people about gcc putting const symbols
in the .text segment and that changed in official gcc 3.4 (or gcc 3.3.3
if using prebuilt compilers from Cygwin/MinGW)

For reference, here's a link to my that request:
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1307365&group_id=2435

So, with a new enough gcc, the segfault should be gone on MinGW as
well, now that the patch is applied.

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]