[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-cygwin
Subject:    Re: ld seg fault while creating import library
From:       Pieter Thysebaert <pieter.thysebaert () intec ! rug ! ac ! be>
Date:       2002-08-19 6:26:05
[Download RAW message or body]

On Friday 16 August 2002 13:37, Ralf Habacker wrote:
> Hi all,
>
> Nicholas Wourms has encountered a segfault on linking qt3, while ld creates
> the import library.
>
> Currently I'm investigating some time to fix this and the first results are
> the following:
>
> ld uses the function pe_dll_generate_implib (def, impfilename) in pe-dll.c
> to create the import library.
> For each object file in the import library a bfd object is created. In
> recent releases this function eats about 30 KB for each object file. The
> qt2 import library contains 12078 objectfile, which needs 350 MB only for
> generating the import library and causes the seg fault in the descripted
> case.
>
> $ nm /usr/local/lib/qt2/lib/libqt.dll.a  | grep ".o:" | wc -l
> 12078
>
> The related functions are in pe-dll.c
>
> pe_dll_generate_implib(def, impfilename)
> 	make_one (exp, parent)
> 		bfd_create()
> 			_bfd_new_bfd()
> !!!!!!!!!!!!!!!!!!!!!!!!!!! These are the functions in which the memory is
> allocated
> 				bfd_zmalloc()
> 				objalloc_create()
> 				bfd_hash_table_init()
> !!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> With the help of a little malloc debugger under
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kde-cygwin/tools/mem_watch/w
>hich i can see, that the memory used by make_one() and subfunctions need
> tweny kilo bytes more than the  kde-cygwin binutils, which is based on the
> official 20011102 release. It seems that there are two additional malloc
> calls in the objalloc related functions in libiberty.
>
> 				make_one (exp, parent)
>
> 		new								old
> malloc(4064)=1ade29d8 [00487a11]            malloc(4064)=0e7e5ec8
> [0047bb95] malloc(20)=1ade39c0 [0047ea54]              malloc(20)=0e7e6eb0
> [00472e1c] malloc(152)=1ade39d8 [00440fac]             malloc(132)=0e7e6ec8
> [0043d7cc] malloc(12)=1ade3a78 [004878b0]              malloc(12)=0e7e6f50
> [0047bad1] malloc(4064)=1ade3a88 [004878d1]           
> malloc(4064)=0e7e6f60 [0047bae7] malloc(12)=1ade4a70 [004878b0]
>
> !malloc(4064)=1ade4a80 [004878d1]
> !malloc(16216)=1ade5a68 [004879b4]
>
> malloc(8)=1ade99c8 [00440f28]               malloc(8)=0e7e7f48 [0043d748]
> malloc(44)=1ade99d8 [0047ea54]              malloc(44)=0e7e7f58 [00472e1c]
> malloc(24)=1ade9a08 [0047ea54]              malloc(35)=0e7e7f88 [00472e1c]
> malloc(18)=1ade9a28 [0047ea54]              malloc(18)=0e7e7fb0 [00472e1c]
> malloc(30)=1ade9a40 [0047ea54]              malloc(41)=0e7e7fc8 [00472e1c]
> malloc(8)=1ade9a68 [0047ea54]               malloc(8)=0e7e7ff8 [00472e1c]
> malloc(160)=1ade9a78 [0047ea54]             malloc(160)=0e7e8008 [00472e1c]
> malloc(8)=1ade9b20 [0047ea54]               malloc(8)=0e7e80b0 [00472e1c]
> malloc(4)=1ade9b30 [0047ea54]               malloc(4)=0e7e80c0 [00472e1c]
> malloc(160)=1ade9b40 [0047ea54]             malloc(160)=0e7e80d0 [00472e1c]
> malloc(8)=1ade9be8 [0047ea54]               malloc(8)=0e7e8178 [00472e1c]
> malloc(4)=1ade9bf8 [0047ea54]               malloc(4)=0e7e8188 [00472e1c]
> malloc(160)=1ade9c08 [0047ea54]             malloc(160)=0e7e8198 [00472e1c]
> malloc(8)=1ade9cb0 [0047ea54]               malloc(8)=0e7e8240 [00472e1c]
> malloc(4)=1ade9cc0 [0047ea54]               malloc(4)=0e7e8250 [00472e1c]
> malloc(160)=1ade9cd0 [0047ea54]             malloc(160)=0e7e8260 [00472e1c]
> malloc(8)=1ade9d78 [0047ea54]               malloc(8)=0e7e8308 [00472e1c]
> malloc(26)=1ade9d88 [0047ea54]              malloc(36)=0e7e8318 [00472e1c]
>
> !malloc(384)=1ade9da8 [00440f67]
> !malloc(20)=1adea030 [00440f28]
>
> Any ideas ?

No ideas to solve this, but I wanted to say that I have encountered a similar 
problem when I tried to build the  wxWindows library from CVS using a 
self-made linux-to-mingw32 cross-compiler (using gcc 3.1, mingw runtime 2.0 , 
binutils 2.12.90: ld uses a LOT of memory (300MB) when trying to link the dll 
or import lib to the dll and then dies; gcc returns with an "internal 
compiler error".

That and a whole binutils rant was on the crossgcc mailing list.

Pieter
_______________________________________________
kde-cygwin mailing list
kde-cygwin@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-cygwin
[prev in list] [next in list] [prev in thread] [next in thread]