ld -r frustration
Tue Jul 27 15:58:00 GMT 2004
> -----Original Message-----
> From: binutils-owner On Behalf Of Alan Modra
> Sent: 27 July 2004 16:11
> Every so often I get a bug report about TOC overflow when linking on
> PowerPC64 Linux. With the automatic multiple TOC support in GNU ld,
> this ought not happen very often; You need a single object file to
> exceed the 64k TOC limit. However, people use "ld -r" to combine
> object files, sometimes very many object files. So they end up with
> a TOC section that's too big. "Too bad", I say. "Don't use ld -r".
> That's not the ideal solution, especially considering that tools
> like libtool use "ld -r" to work around command line limits when
> linking huge numbers of object files. What we really need is a
> "ld -r" that doesn't do any merging of sections, or a final link
> stage that can undo the effects of "ld -r". The latter would need
> quite a bit of work, and probably not be very robust. I'm leaning
> towards the idea of making "ld -r" behave like "ar cr" on PowerPC64.
a) tell people "Too bad, don't use 'ld -r', use 'ar cr' instead", possibly
by means of a standard form letter you autoreply to bug reports with,
b) get libtool to use "ar cr" as standard,
c) add a bit to the docs explaining why, if you want an archive of object
files, you should use an archive, and not a partial link, which is a far
more complex transformation, rather than a mere innocuous bundling-together.
IOW, I think it's the user expectations that are wrong here.
Maybe that warning you just added to ppc_frob_file_before_adjust should be
extended to say "Hey, are you misusing a partial link as a library archive
without realising what serious behind-the-scenes manipulation it performs?
Maybe you'd be better off with 'ar cr' instead?"
Can't think of a witty .sigline today....
More information about the Binutils