On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote: > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made >>> to >>> the darwin assembler which effectively breaks LTO support for darwin. The >>> design >>> of LTO on darwin was based on the fact that mach-o object files tolerated >>> additional >>> sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the >>> assembler >>> appears to be strictly counting sections and objecting when these exceed >>> 255. This >>> breaks huge sections of the lto testsuite and prevents larger projects like >>> xplor-nih >>> to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple >>> reverts this >>> change, our only recourse would be to resort to an elf object container for >>> the lto >>> sections within the mach-o files (introducing an undesired dependency on >>> libelf for >>> FSF gcc on darwin). My understanding was that the lto design did not allow >>> the number >>> of sections required in the lto files to be reduced. >> >> If the problem is not fixed, we could always pack all the LTO sections into >> one section containing >> our own subsections. >> >> Honza > > Jan, > If this could be done without resorting to other container types (like elf), > it might be > the wisest approach for the long run. I've read through the mach-o > documentation and it > seems rather vague on the section limits. Even if Apple fixes Xcode (which > likley won't > happen for 6-9 months at best), we always we have to worry that they will > break this > 'feature' somewhere else in their tool chain. Better to follow the strictest > possible reading > of mach-o object format to protect ourselves from overzealous Apple interns.
Yes, I agree that this is a better solution. This error was put into the linker to detect some overflow conditions for part of the code that expected the section number to only be a byte. It is likely that "things worked" only out of luck before. -Chris
