The package dev-libs/glib-2.40.2 fails to build on OS X Yosemite because it automatically detects OS X and tries to build a framework, which fails due to the new interfaces. Building manually with carbon/cocoa disabled works without problems. Reproducible: Always
Created attachment 387906 [details] build.log
Created attachment 387908 [details, diff] glib-2.40.2-osx.patch This is a patch to correct automagic detection of OS X by glib-2.40.2.
Created attachment 387910 [details] glib-2.40.2-r1.ebuild This new ebuild adds the USE flag aqua. On Yosemite, USE=-aqua compiles normally.
I'm not sure if the aim of USE=-aqua for Yosemite is the best thing to do. I'd rather see movement on fixing Clang.
Yes, this is just a workaround so I could get a working prefix. In any case, it is better to have the USE flag to turn on or off. Now that I got a prefix working, I can test stuff more easily. I would have done more work on clang already if I were more familiar with how to create new profiles, etc. Maybe we should set up a time for a chat at #gentoo-prefix about how to work on using clang when you have time.
Fixed for now due to using clang for python.
So how is this bug fixed? Looks like it was fixed by using clang instead of gcc (I can see from the build log), but I can't find where the black magic been added. Also the current fix is not ideal. I have sys-devel/clang installed so when building glib the clang in $EPREFIX will be used and failed in ./configure step. Tried to set CC=/usr/bin/clang in make.conf without uninstalling sys-devel/clang but it doesn't work. I finally installed sys-devel/glib by uninstall clang from prefix.
Someone did a crude hack, because of a preference to generate other problems over just fixing the thing the right way.
(In reply to Fabian Groffen from comment #8) Fabian, we are using the host clang because you said my fix of compiling without aqua support with gcc-apple was not acceptable. Yes, using the host clang is not the ideal solution, but the prefix-provided clang doesn't work yet, as far as I know. If it does, I'll be happy to look into using it to compile glib. In the mean time, our users needed a working bootstrap process on Yosemite, so the temporary fix is to compile some packages like python and glib with host clang while the prefix clang doesn't work. Once the prefix-provided clang is patched appropriately, we will fix this and other packages to use it instead. What Ruud and I didn't want was to leave Yosemite bootstrap broken while the prefix clang isn't ready, because several users were trying to bootstrap and failing. @yegle: The fix is currently in the file ${EPREFIX}/usr/portage/profiles/darwin/macos/10.10/profile.bashrc if you'd like to change anything. BTW, how did you emerge clang in your prefix? Last time I tried, it didn't compile for me. Also, should we reopen this bug and only close it after proper clang support in prefix has been merged?
