Output from g++ -v [/Volumes/Gentoo is my EPREFIX]: #include "..." search starts here: #include <...> search starts here: /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/include/g++-v4 /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/include/g++-v4/i686-apple-darwin9 /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/include/g++-v4/backward /Volumes/Gentoo/usr/include /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/gcc/i686-apple-darwin9/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) Please note that '/Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/gcc/i686-apple-darwin9/4.2.1/include' contains 'gcc/i686-apple-darwin9/4.2.1' two times. This causes build failure in boost, as it is unable to find cxxabi.h (installed into /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/include).
I seem to have the same problem, I'll look into it. /Library/Gentoo/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/gcc/powerpc-apple-darwin8/4.2.1/include
still no luck from my side where this path is generated in gcc
any hints here are appreciated, as I can't seem to find where it comes from.
this problem is not limited to gcc-apple
(In reply to comment #3) > any hints here are appreciated, as I can't seem to find where it comes from. > I tracked that one down as being a result of the configure argument "--libdir=${LIBPATH}" in the gcc-apple-4* ebuilds (gcc-apple-3* doesn't have that flag). According to ${S}/gcc/Makefile.in that flag is used to build: libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version) which in turn is used for the final include path: -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" As you can see, if $(libdir) is set to ${EPREFIX}/usr/lib/gcc/${CTARGET}/${GCC_VERS} the gcc/$(target_noncanonical)/$(version) is appended and the resulting include path will be ${EPREFIX}/usr/lib/gcc/${CTARGET}/${GCC_VERS}/gcc/$(target_noncanonical)/$(version) or in the original poster's case: /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/gcc/i686-apple-darwin9/4.2.1 Removing the line "--libdir=${LIBPATH}" from the ebuild fixes the include path, BUT places libs in $EPREFIX/usr/lib. So this is a no-go for multiple gcc-versions. Instead it suffices to patch the line libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version) in ${S}/gcc/Makefile.in to libsubdir = $(libdir) that is, take the "--libdir=${LIBPATH}" argument as proper offset for libs and includes. I just recompiled gcc-apple and gcc still works (yay) and boost compiles just fine with the fix.
Created attachment 184078 [details, diff] Patch against prefix portage tree to fix the include path for gcc-apple-4.2.1-5566 This is probably also a fix for gcc. I still wonder when that problem arose, since i had boost installed some time ago.
Comment on attachment 184078 [details, diff] Patch against prefix portage tree to fix the include path for gcc-apple-4.2.1-5566 This is probably also a fix for gcc. Anyway, the libgomp header omp.h is still placed in the wrong directory. I'll post a fix for that as well, tomorrow. I still wonder when that problem arose, since i had boost installed some time ago.
Created attachment 184114 [details, diff] Patch against prefix portage tree to fix the include path for gcc-apple-4.2.1-5566 Fix works for at least these use flags settings: sys-devel/gcc-apple-4.2.1_p5566 USE="nls objc objc++ -multislot -nocxx -test"
(In reply to comment #4) > this problem is not limited to gcc-apple > It gets even worse: otool -L PGQt.app/Contents/MacOS/PGQt | grep c++ /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) cd /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/gcc/i686-apple-darwin9/4.2.1 ln -s ../../../libstdc++.6.dylib ln -s ../../../libstdc++.dylib ln -s ../../../libstdc++.6.0.4.dylib recompile otool -L PGQt.app/Contents/MacOS/PGQt | grep c++ /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) I guess you'll get the point. So I'm going to dig a bit more into that gcc-cruft.
Ok, turned out to be simpler as I thought. Just replace "--libdir=${LIBPATH}" with "--enable-version-specific-runtime-libs" in the ebuild. This makes the gcc build-scripts set up the libraries and headers in a version specific directory (by internally using --slibdir=...), namely $(libdir)/gcc/$(target_noncanonical)/$(version) that is /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1
Created attachment 184137 [details, diff] Fix against current svn of the portage prefix tree's gcc-apple-4.2.1_p5566. Finally fix the problem in a clean manner. Since the patch sets up the include AND shared lib dirs properly, this also resolves the wrong linking to /usr/lib/libstdc++.6.dylib: otool -L `which scummvm` | grep c++ /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) This fix should also be applied to the other sys-devel/gcc-apple ebuilds and maybe sys-devel/gcc as well (that should be tested before).
patch committed with version bump, hope it fixes the issues :( Thanks heiko_ for the research!
shouldnt the eclass be checking CTARGET and not CHOST ?
eh, yes, committed.
