Currently, in order to get libffi installed, there is a separate ebuild from the gcc ebuild. The libffi ebuild is a different version than the gcc version that is on my system and this is causing unstable GNUstep apps. I don't want to set gcj to get libffi as I don't use java, plus it adds over an hour of compile time. There needs to be some sort of USE flag for gcc so that it will install libffi, without compiling all the java stuff. This would also cut down on download time since the libffi ebuild must download another version of gcc just to compile and install libffi. Thank you.
Just a note, but I would be really great to see this feature add to gcc. Keeping libffi (as a seperate ebuild) "in sync" with a user's gcc is gravely annoying. Currently, libffi is only installed with gcj enabled, it seems. Please check dev-libs/libffi/files for patches to allow libffi to build w/o gcj enabled (simple configure changes). There has been a large handful if issues that have mysteriously disappeared when a user used a libffi version that was "in sync" with their gcc install, and this feature would completely do away with that problem. Offering big hugs if someone in toolchain fixes this. I would have done so already, but I honestly don't want to monkey around with the gcc ebuilds. :-\
Created attachment 44745 [details, diff] configures gcc 3.4.X series to not make libffi a dependency of solely libgcj
Created attachment 44746 [details] Example gcc 3.4.1 with libffi
Created attachment 44747 [details] Example gcc 3.4.3 with libffi
The newly added patches allow libffi to be built by itself when gcc is installed. They depend on a local use flag of 'libffi'. It works for the example ebuilds. For my needs for this bug, I'm okay requiring gcj when libffi is needed in gcc-3.3.X series.
could you submit just a diff for 3.4.3? it's easier to see what you actually changed this way.
added myself to the CC list
Created attachment 44804 [details] Differences for libffi use flag for ebuild (works with posted gcc patch)
this requires some further editing to work as expected all the time and not have multiple gcc versions clash. but dont worry, i'll get to it.
...and while making sure libs dont get installed outside the gcc ${LIBPATH} i noticed that the libtool libdir fixer thingie has been broken since pre-3.3.3 days and nobody noticed. so yeah, that needs to be fixed too. o.o
added to 3.4.3-r1
Created attachment 44896 [details, diff] Fixes libffi configure and Makfile scripts to install into the correct taget directory - works with the other libffi gcc patch (use it right after the first patch) - seems to fix paths in the .la file too
