llvm dev - May 2012 - [LLVMdev] Linking clang.exe takes more than two hours?

Hi,

I'm building using MINGW64 on a very slow system (Intel Atom 330 X2 1.6
GHz), but it seems rather odd that the system has been linking clang.exe
for the past two hours.  It appears that a couple of gigabytes of virtual
memory are being used (causing constant swapping) - the system has only 2
GB of physical memory.

Is this a bug in MINGW64 (binutils 2.22) or is it just too little RAM in
the build machine?  After all, clang.exe is only about 35 megabytes or so,
so you'd think that it didn't take four gigabytes to link the
executable.
 But then again, the input libraries to clang.exe take up about 1.2
gigabyte.  If the GNU/MINGW64 linker naively reads all library files into
memory and then searches about to resolve unresolved symbols, I guess it
could cause excessive trashing during link.


Cheers,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120527/6fe54147/attachment.html>

于 2012/5/27 11:04, Mikael Lyngvig 写道:
> Hi,
>
> I'm building using MINGW64 on a very slow system (Intel Atom 330 X2 
> 1.6 GHz), but it seems rather odd that the system has been linking 
> clang.exe for the past two hours.  It appears that a couple of 
> gigabytes of virtual memory are being used (causing constant swapping) 
> - the system has only 2 GB of physical memory.
>
> Is this a bug in MINGW64 (binutils 2.22) or is it just too little RAM 
> in the build machine?  After all, clang.exe is only about 35 megabytes 
> or so, so you'd think that it didn't take four gigabytes to link
the
> executable.  But then again, the input libraries to clang.exe take up 
> about 1.2 gigabyte.  If the GNU/MINGW64 linker naively reads all 
> library files into memory and then searches about to resolve 
> unresolved symbols, I guess it could cause excessive trashing during link.
>
>
> Cheers,
> Mikael
>
>
Which edition of your gcc?

If newer than gcc4.6 (including 4.6), you may try to add 
-fno-keep-inline-dllexport to your compiler option, this will improve 
your link issues.


-- 
Best Regards,
xunxun

G++/Mingw64 v4.7.1, ld v2.22.52.  I've been checking out the process
list and ld uses 2.6 gigabytes of memory on a 2 gigabytes system.  So,
I hereby learned that you need at least 4 gigabytes in your wannabe
LLVM build system :-)

I'll try your option sometime when the build is complete.  It may take
hours or days until that.


Cheers,

Mikael


2012/5/27 xunxun <xunxun1982 at gmail.com>
> 于 2012/5/27 11:04, Mikael Lyngvig 写道:
>
>> Hi,
>>
>> I'm building using MINGW64 on a very slow system (Intel Atom 330 X2
1.6
>> GHz), but it seems rather odd that the system has been linking
clang.exe
>> for the past two hours.  It appears that a couple of gigabytes of
virtual
>> memory are being used (causing constant swapping) - the system has only
2
>> GB of physical memory.
>>
>> Is this a bug in MINGW64 (binutils 2.22) or is it just too little RAM
in
>> the build machine?  After all, clang.exe is only about 35 megabytes or
so,
>> so you'd think that it didn't take four gigabytes to link the
executable.
>>  But then again, the input libraries to clang.exe take up about 1.2
>> gigabyte.  If the GNU/MINGW64 linker naively reads all library files
into
>> memory and then searches about to resolve unresolved symbols, I guess
it
>> could cause excessive trashing during link.
>>
>>
>> Cheers,
>> Mikael
>>
>>
>>  Which edition of your gcc?
>
> If newer than gcc4.6 (including 4.6), you may try to add
> -fno-keep-inline-dllexport to your compiler option, this will improve your
> link issues.
>
>
> --
> Best Regards,
> xunxun
>
>

-- 
-- Earth is a soddy place.  Stay away!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120527/4e71e9a3/attachment.html>