[Top][All Lists]

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

Re: 答复: Re: ´ð¸´: Re: How large file can be processed by the linker "ld

From: Nick Clifton
Subject: Re: 答复: Re: ´ð¸´: Re: How large file can be processed by the linker "ld"?
Date: Mon, 17 Nov 2008 17:04:43 +0000
User-agent: Thunderbird (X11/20080723)

Hi shihhuangti,

it is diffcult to me to explain why this happens, for the memory required by the second step should be smaller the the first step(because the ld can drop some section within every obj file); and the first functions, why the second doesn't?

Because when the linker performs a full link it has to do a lot more processing that when it just performs a relocatable link. This means that it has to use more memory in order to perform this extra processing.

additionly, the ld doesn't generated any message like "memory exhausted" which it does when I want to generate a exe-file (have hot reloc info), So I think the error happens during at second step may due to some other cause but not about the available memory amount.

But - the problem does not happen if you do not compile with the -g3 compiler switch, correct ? So either the linker is exhausting memory, but it is failing to report it, or else there is some kind of problem with the linker's processing of the debug information.

So - are you able to make a small test case that fails ? Ie just one small object file compiled with -g3 which triggers the linker crash ? I suspect that you will not be able to do this, because I think that the problem is more likely to be the first sceanario, (ie the linker running out of memory but not reporting it properly).

I presume that you do not have access to a machine with more memory with which to test this theory ? (Or maybe you could increase the amount of virtual memory available on the machine that you are using). If you could do this you could find out if memory resources are causing the problem.


reply via email to

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