This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
AW: status porting kde2 - ld crashes
- To: "Binutils" <binutils at sources dot redhat dot com>
- Subject: AW: status porting kde2 - ld crashes
- From: "Ralf Habacker" <Ralf dot Habacker at saght dot tessag dot com>
- Date: Thu, 31 May 2001 09:54:50 +0200
> -----Ursprüngliche Nachricht-----
> Von: binutils-owner@sources.redhat.com
> [mailto:binutils-owner@sources.redhat.com]Im Auftrag von Ralf Habacker
> Gesendet am: Donnerstag, 31. Mai 2001 09:28
> An: Binutils
> Betreff: Re: status porting kde2 - ld crashes
>
> Hello Ralf,
>
> Ralf Habacker <Ralf.Habacker@saght.tessag.com> wrote on Wednesday, May 30,
> 2001:
>
> RH> Hi Paul,
> RH> The current state on cpmpiling kde2 is, that kdesupport and
> kdecore are
> RH> compiled, but while compiling kdeui the linker crashes after consuming
> 390
> RH> MB RAM. I have looked in the source and found that it crashes in
> RH> bfd_find_target() (see below).
>
> RH> Do you have any ideas, what I can do ?
>
> My guess is that it crashes just due to vm exhaustion (i.e. NULL
> from malloc returned somewhere and passed there). I also can imagine I
> know the reason why so much core is used at all - due to the way
> virtual inline functions are handled by ld (remember, auto-import
> problem was also related to this). The virtual inlines are spewed into
> comdat (aka linkonce) sections, duplicated multiple times in object
> files/ It seems that ld sifts them into non-optimal way: first, loads
> them all together and only them starts hard shuffling to get rid of
> duplicates, instead of doing the check on load. I faced the problem,
> of course, but my solution was to split big dll into bunch of small
> ones. I understand that's not the solution in your case, but it worked
> for me, so I never really tried to test validity of the hypothesis or
> fix it.
>
>
Does anyone have an idea what to do ?
Regards Ralf