Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. John L. From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On 11 Jan 2012, at 13:38, John Lato wrote: I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. GCC 4.6.2 builds on OS X 10.7 with Xcode 4.2. Build GMP 5.0.2 with clang, and then GCC with /usr/bin/gcc - llvm-gcc-4.2. I think I saw someone guild GCC 4.7, but this is highest stable. Hans From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Thanks, looks like I already succeeded by downloading xcode 3. Now my original question remains - is such a change a good idea? (I've already found the place in code where the fix has to be made; should take an hour of work at most) On Wed, Jan 11, 2012 at 6:07 PM, Hans Aberg haber...@telia.com wrote: On 11 Jan 2012, at 13:38, John Lato wrote: I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. GCC 4.6.2 builds on OS X 10.7 with Xcode 4.2. Build GMP 5.0.2 with clang, and then GCC with /usr/bin/gcc - llvm-gcc-4.2. I think I saw someone guild GCC 4.7, but this is highest stable. Hans From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Hi Eugene, I think I did run into this problem before, and had to turn of split-objs temporarily to work around it. I'd appreciate a fix. Best, Ozgur On 11 January 2012 14:14, Eugene Kirpichov ekirpic...@gmail.com wrote: Now my original question remains - is such a change a good idea? (I've already found the place in code where the fix has to be made; should take an hour of work at most) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov ekirpic...@gmail.comwrote: 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
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 allber...@gmail.comwrote: On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov ekirpic...@gmail.comwrote: 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 allber...@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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On Wed, Jan 11, 2012 at 14:50, Eugene Kirpichov ekirpic...@gmail.comwrote: 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) Only if it works; my expectation is that all you will accomplish is to move the failure point, as the command line for ld is usually larger than the one for gcc. It is possible that gcc will do something to deal with it itself, but I have a suspicion that only works (if it does) with binutils ld, which is not usable on OS X. BTW, I'm actually suggesting that split-objs create an archive, where non-split-objs creates an object; from there I suspect you wouldn't actually need to handle anything any differently between the two cases (aside from specifying the .a instead of the .o as needed). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Hi, I'm building gtk2hs on a mac with -fsplit-objs, and during compilation of the largest file, which produces about 7000 split objects, the linking phase fails. I'm assuming that's because the command line length has been exceeded, because other files compile fine, without -fsplit-objs it compiles fine too, and it compiles fine *with* -fsplit-objs on other OS - so perhaps the reason is in mac's tempfile name generation (they're longer than on other platforms) or something. Anyway. 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. It'd be fun for me to implement this as my first contribution to ghc; is this a good idea in general? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) On Wed, Jan 11, 2012 at 11:12 AM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hi, I'm building gtk2hs on a mac with -fsplit-objs, and during compilation of the largest file, which produces about 7000 split objects, the linking phase fails. I'm assuming that's because the command line length has been exceeded, because other files compile fine, without -fsplit-objs it compiles fine too, and it compiles fine *with* -fsplit-objs on other OS - so perhaps the reason is in mac's tempfile name generation (they're longer than on other platforms) or something. Anyway. 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. It'd be fun for me to implement this as my first contribution to ghc; is this a good idea in general? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
