Hi Brandon, Thanks - looks like this would be a modification of the linking stage, splitting it into two parts: batching objects and then actually linking them. Do you think that what I originally proposed is still a good thing to have before implementing your solution? (it definitely would be for myself, as it's easier to do and I'd then quicker become able to build my application with split-objs and shrink its executable size from 11 to 2Mb) On Wed, Jan 11, 2012 at 9:48 PM, Brandon Allbery wrote:

On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov wrote:

...

I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files.

What immediately occurs to me is, what if the problem (or another manifestation of same) occurs in the ld step? OS X's ld(1) doesn't have such an option /per se/, and binutils ld(1) does not reliably create valid Mach-O objects.

I would consider "batching" split-objs files into static archives (see ar(1) and ranlib(1)). This also has the advantages of being portable (other platforms other have length limits; I believe it's the main reason split-objs is disabled by default on e.g. Solaris) and that with many linkers it's faster than individual objects because it can use the archive table of contents to speed up searching for files and symbols.

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

-- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/