Created attachment 266227 [details] build.log Hi folks, the package mentioned in the ebuild does not compile on my Mac Mini G4. emerge --info and the build log will be attached. Failure: make -j1 make -C build/lib all; make[1]: Entering directory `/var/tmp/portage/dev-libs/STLport-5.2.1/work/STLport-5.2.1/build/lib' powerpc-unknown-linux-gnu-g++ -pthread -fexceptions -fPIC -fvisibility=hidden -O2 -mcpu=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -ggdb3 -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp In file included from ../../stlport/vector:38, from ../../src/dll_main.cpp:43: ../../stlport/stl/_vector.h:714: error: expected declaration before â}â token make[1]: *** [obj/gcc/so/dll_main.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-libs/STLport-5.2.1/work/STLport-5.2.1/build/lib' make: *** [all] Error 2 emake failed Cheers, T.
Created attachment 266229 [details] emerge --info output redacted for privacy
i imagine if you drop the altivec stuff from your CFLAGS it'll build
(In reply to comment #2) > i imagine if you drop the altivec stuff from your CFLAGS it'll build Quite possible but certainly not an option since the older versions obviously built fine with Altivec support enabled. Therefore this is a regression and should be addressed.
Does the code even benefit from the altivec flags? Why not make the ebuild just strip those flags if they're present? I highly doubt they're making much use of the SIMD intrinsics here.
Do you have any proof for your statement? Assembler code perhaps that supports your claim? The point is that it does not matter if the code benefits from the option that enables Altivec optimisation or any other. -O2 comes to mind. The point is that this optimisation had been previously enabled and now it - the package - failed to compile. Cheers, T.
commit 967d0ecf3f118dae84b7d100d3464f26cc3d33f7 Author: David Seifert <soap@gentoo.org> Date: Sun May 7 09:47:53 2017 +0200 dev-libs/STLport: Remove from tree
