<div dir="ltr">On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov <span dir="ltr">&lt;<a href="mailto:ekirpichov@gmail.com">ekirpichov@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think a nice fix would be to employ gcc&#39;s ability to read options from a file - gcc @file - and write overly long option strings into temp files.</blockquote></div><br>What immediately occurs to me is, what if the problem (or another manifestation of same) occurs in the ld step?  OS X&#39;s ld(1) doesn&#39;t have such an option /per se/, and binutils ld(1) does not reliably create valid Mach-O objects.<div>
<br></div><div>I would consider &quot;batching&quot; 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&#39;s the main reason split-objs is disabled by default on e.g. Solaris) and that with many linkers it&#39;s faster than individual objects because it can use the archive table of contents to speed up searching for files and symbols.<br clear="all">
<div><br></div>-- <br>brandon s allbery                                      <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available)     (412) 475-9364 vm/sms<br>
<br>
</div></div>