[Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix

[Eugene Kirpichov]

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 <allbery.b at gmail.com>wrote:

> On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov <ekirpichov at gmail.com>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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120111/36612d76/attachment.htm>