* incremental ld ? @ 2000-07-15 3:12 Shyjan Mahamud 0 siblings, 0 replies; 2+ messages in thread From: Shyjan Mahamud @ 2000-07-15 3:12 UTC (permalink / raw) To: binutils hello, are there any plans for an incremental version of ld (i don't mean 'ld -r') ? or is there one already ? it is a shame to have to wait *12 min* for the linker to build from scratch when i may have changed just one line of code. thanx - shyjan ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <mahamud@marr.ius.cs.cmu.edu>]
[parent not found: <200007151013.DAA22014@neosilicon.transmeta.com>]
[parent not found: <20000715154748.89DEE8CB2F@vole.transmeta.com>]
* Re: incremental ld ? [not found] ` <20000715154748.89DEE8CB2F@vole.transmeta.com> @ 2000-07-15 16:14 ` mahamud 0 siblings, 0 replies; 2+ messages in thread From: mahamud @ 2000-07-15 16:14 UTC (permalink / raw) To: Steve Chamberlain; +Cc: binutils thanx for the prompt reply! >> Let me guess - it's a large g++ project compiled with debygging >> ? I had something like this last year. I fixed it by sending yes, a module for the mozilla browser project. >> in a patch to ld which did better hashing for the debugging >> info (which halved the time) and compiling fewer files with i assume that this patch has been incorporated into the current ld. >> debugging turned on (which got the time to somewhere just >> beyond painful). i did'nt think of this before. i have tried it now, it cuts down on the space a lot - from ~50MB to ~14MB, but it shaved off only ~2 min from the 12 min link time. >> (My next step would have been to split the binary into >> different shared objects) the code is divided into lots of shared objects, but the problem i am facing is while creating another shared object from a bunch of objects and other shared objects. most of the object files are not modified. if i wanted to create a final executable, then i would use your suggestion and create a new shared object from the object files that don't get modified and use that along with other shared objects and the object files that get modified to create the executable. i have tried an alternative suggested by the ld man page. i used 'ld -Ur' to create a relocatable file from all the object files that don't get modified. the man page claims that further linking should be faster with such a relinkable object file. i then create the shared object i want with this relinkable object file along with the modified object files (as well as other shared objects). Surprisingly things get worse, ~20 min vs. 12 min. without 'ld -Ur'. am i doing something wrong ? while on this topic of relinkable objects, i would like to ask why i cannot link in shared objects with the 'ld -Ur' option ? i can only link in these shared objects while creating the final shared object using a normal ld. is this a limitation of the current implementation of gnu ld or is it fundamentally not possible (i am not a compiler/linker expert). i would think that if it was possible to link in shared objects with 'ld -Ur' then a lot more symbols could get resolved upfront, thus avoiding having to resolve these symbols while creating the final shared object. any comments and help would be appreciated. thanx - shyjan ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-07-15 16:14 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-15 3:12 incremental ld ? Shyjan Mahamud [not found] <mahamud@marr.ius.cs.cmu.edu> [not found] ` <200007151013.DAA22014@neosilicon.transmeta.com> [not found] ` <20000715154748.89DEE8CB2F@vole.transmeta.com> 2000-07-15 16:14 ` mahamud
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).