ffi.h (and ffitarget.h) are installed in /usr/lib/libffi-3.0.8/include, but not in /usr/include (or somewhere else where GCC can find them). Reproducible: Always Steps to Reproduce: 1. emerge libffi 2. echo "#include <ffi.h>" > main.c 3. echo "int main(int argc, char* argv[]) { return 0; }" >> main.c 4. gcc -lffi main.c Actual Results: main.c:1:17: error: ffi.h: No such file or directory Expected Results: Successful compilation. I'm on GCC 4.1.2, which doesn't seem to install its own libffi. Note that the man page ("man ffi") indicates that "#include <ffi.h>" is the correct, standard way to access ffi.h.
That's because it has pkg-config to point you in the right direction, like: gcc `pkg-config --cflags-only-I libffi` -lffi main.c
(In reply to comment #1) > That's because it has pkg-config to point you in the right direction... That's a terrible answer. It's the only library I know of that hides its headers somewhere in /usr/lib rather than in /usr/include. And the manpages make no reference to the pkg-config requirement. (In my case, I'm using it in a non-Makefile-based project so it really is an issue for me.) However, I can see that this idiocy is libffi's fault, not Gentoo's, and that Gentoo is only trying to be faithful to the upstream.
I agree. See, 13 Jun 2008; Samuli Suominen <ssuominen@gentoo.org> +files/libffi-3.0.5-includedir.patch, libffi-3.0.5.ebuild: Fix includedir. USE flag test for dejagnu which is required for make check. I once installed it the way you wanted, but someone complained. Can't recall if he had any good reasoning to go with it... Is there any chance you could mail libffi's upstream about this?
This issue persists, dev-libs/libffi-3.0.8 still installs its headers into /usr/lib64/libffi-3.0.8/ instead of /usr/include/.
(In reply to comment #4) > This issue persists, dev-libs/libffi-3.0.8 still installs its headers into > /usr/lib64/libffi-3.0.8/ instead of /usr/include/. > The bug was reported against 3.0.8 if you read Comment #0. And I'm still waiting for someone to post this on upstream mailing list per Comment #3. http://sourceware.org/libffi/ So, if you want to help, start there.
(In reply to comment #5) > (In reply to comment #4) > > This issue persists, dev-libs/libffi-3.0.8 still installs its headers into > > /usr/lib64/libffi-3.0.8/ instead of /usr/include/. > > > > The bug was reported against 3.0.8 if you read Comment #0. Oh, I am sorry. Reading in the last comments about 3.0.5 I thought it was against an older version. > And I'm still > waiting for someone to post this on upstream mailing list per Comment #3. You mean in 2 months no one managed to write one simple email?
(In reply to comment #6) > (In reply to comment #5) > > And I'm still > > waiting for someone to post this on upstream mailing list per Comment #3. > You mean in 2 months no one managed to write one simple email? Done, see this post: http://sourceware.org/ml/libffi-discuss/2009/msg00248.html
(In reply to comment #7) > > And I'm still > > waiting for someone to post this on upstream mailing list per Comment #3. > You mean in 2 months no one managed to write one simple email? I could be writing mails all day for different packages and never get done... it's priorities. > Done, see this post: http://sourceware.org/ml/libffi-discuss/2009/msg00248.html > Thanks, let's see what they reply. I'll apply the patch in tree unless they have very good reason not to.
Anthony Green from Redhat replied to me directly when I mailed him about the include directory. His answer was the same as I already gave you, use pkg-config --cflags to include the libffi's include directory in path.
I'd like to point also that it's a perfectly valid location for the includes. ssuominen@unique /usr/lib $ find ./ -name '*.h' | wc -l 4804 4804 includes in /usr/lib here, most of them (if not all) use pkg-config to determine the path.
