Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199909271916.OAA11513@mercury.xraylith.wisc.edu>
To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Re[2]: ld or gcc failing? 
In-Reply-To: Your message of "Sat, 25 Sep 1999 22:58:03 +0300."
             <3956 DOT 990925 AT is DOT lg DOT ua> 
Date: Mon, 27 Sep 1999 14:16:13 -0500
From: Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>

Paul Sokolovsky <paul-ml AT is DOT lg DOT ua> writes:
> 
>     Is reloc overflow the only problem with incremental linking? I was
> unable to use it at all. Never tried for trivial example, but using it
> when it is really needed, e.g. when linking megabytes of C++ code
> gives nonsense. From quick look, following wrong things are being done:

Paul,

Reloc overflow is a problem with all linking, but I don't know off hand
if reloc overflow is the only problem with incremental linking. I fear
there are others as well, and since incr linking is never quite as well
tested as "regular" linking, the bugs come out slowly over time.

>       Groupping of subsections is performed. This is bad idea because
> different subsections can have different attributes.
> 
>       Anything except .text,.data,.dtor,.ctor,.bss seem to be
> discarded (.drectve, mainly).

I believe this is fixed in the snapshots, but I need to make sure.

>       For example, look what nonsense gives linking 6 objects of total
> size 300k and full of .text$ comdats for dllexported inlines and
> .data$ comdats for virtual tables:

Ah, the joys of "interesting" comdat issues in the current binutils. 
There's work on going, so please have patience. I'm sure Ian is still 
chugging through the large set of patches from Donn Terry ...

>    So, I would like to ask is this a bug in pe/coff handling or ld
> just cannot catch up with g++ ?

The issue is really comdat handling more than having to catch up to
g++. Once comdats are handled correctly, g++ support will implicitly
work.

What binutils snapshot did you try these with?  

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com