Pretty sure the proper location for header files is /usr/include not /usr/lib64. Also not sure the directory should be versioned. Headers should be /usr/include/libffi Instead they are installed to /usr/lib64/libffi-3.2.1/include I believe that location is incorrect.
It was an upstream decision to hide headers behind ABI-specific directory because headers were platform-specific (and are in latest release): $ diff -raN -U0 /usr/lib32/libffi-3.2.1/ /usr/lib64/libffi-3.2.1/ @@ -61,2 +61,2 @@ -#ifndef X86 -#define X86 +#ifndef X86_64 +#define X86_64 Upstream cleaned includedir up recently in git by making headers less platform-specific. The final upstream change after making headers platform-agnostic: https://github.com/libffi/libffi/commit/982b89c01aca99c7bc229914fc1521f96930919b But libffi didn't have a release for years. We might need to pull in a few patches to make it happen earlier in gentoo.
Wrapping /usr/include/ffi.h with multilib helper as: MULTILIB_WRAPPED_HEADERS=( /usr/include/ffi.h ) causes python to fail to build against such libffi: sf Python-3.6.4 $ LANG=C make V=1 running build running build_ext Header file /usr/include/ffi.h does not define LIBFFI_H or ffi_wrapper_h INFO: Can't locate Tcl/Tk libs and/or headers warning: building with the bundled copy of libffi is deprecated on this platform. It will not be distributed with Python 3.7 error: [Errno 2] No such file or directory: '/dev/shm/portage/dev-lang/python-3.6.4/work/Python-3.6.4/Modules/_ctypes/libffi' make: *** [Makefile:597: sharedmods] Error 1 $ cat /usr/include/ffi.h /* This file is auto-generated by multilib-build.eclass * as a multilib-friendly wrapper. For the original content, * please see the files that are #included below. */ #if defined(__x86_64__) /* amd64 */ # if defined(__ILP32__) /* x32 ABI */ # error "abi_x86_x32 not supported by the package." # else /* 64-bit ABI */ # include <x86_64-pc-linux-gnu/ffi.h> # endif ...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6b286d934352693e1f9a9cabfe567884e28b0cb5 commit 6b286d934352693e1f9a9cabfe567884e28b0cb5 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-01-06 13:02:51 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-01-06 13:03:17 +0000 dev-libs/libffi: allow includedir= override, bug #643582 It's not a fix for bug #643582 as includes location did not change. But a step towards it. Changes are: - updated to EAPI=6 - backported upstream commit https://github.com/libffi/libffi/commit/982b89c01aca99c7bc229914fc1521f96930919b ("Install public headers in the standard path") - but overrode default location as --includedir=/usr/$(get_libdir)/${P}/include/ to keep python from breaking: bug #643582#c2. Reported-by: William L. Thomson Jr. Bug: https://bugs.gentoo.org/643582 Package-Manager: Portage-2.3.19, Repoman-2.3.6 .../libffi/files/libffi-3.2.1-complex_alpha.patch | 4 +- .../files/libffi-3.2.1-include-path-autogen.patch | 56 ++++++++++++++++++ .../libffi/files/libffi-3.2.1-include-path.patch | 39 ++++++++++++ dev-libs/libffi/libffi-3.2.1-r1.ebuild | 69 ++++++++++++++++++++++ 4 files changed, 166 insertions(+), 2 deletions(-)}
To force includedir into /usr/include/ you can use environment variables: MULTILIB_WRAPPED_HEADERS=/usr/include/ffi.h EXTRA_ECONF=--includedir=/usr/include/ emerge -v1 =libffi-3.2.1-r1
MULTILIB_WRAPPED_HEADERS doc at https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/multilib-build.eclass#n319 says: """ # Please note that header wrapping is *discouraged*. It is preferred to # install all headers in a subdirectory of libdir and use pkg-config to # locate the headers. Some C preprocessors will not work with wrapped # headers. """ $ ls -d1 /usr/lib32/*/include /usr/lib32/atkmm-1.6/include /usr/lib32/cairomm-1.0/include /usr/lib32/dbus-1.0/include /usr/lib32/gdkmm-3.0/include /usr/lib32/giomm-2.4/include /usr/lib32/glib-2.0/include /usr/lib32/glibmm-2.4/include /usr/lib32/gnome-vfs-2.0/include /usr/lib32/gstreamer-1.0/include /usr/lib32/gtk-2.0/include /usr/lib32/gtkglext-1.0/include /usr/lib32/gtkmm-3.0/include /usr/lib32/libffi-3.2.1/include /usr/lib32/libxml++-2.6/include /usr/lib32/pangomm-1.4/include /usr/lib32/sigc++-2.0/include /usr/lib32/tcl8.6/include /usr/lib32/tk8.6/include /usr/lib32/wx/include libffi behaves the same. Closing as INVALID.
Thanks I guess its all moot so long as using pkg-config. Thanks again sorry for the waste of time.
Could this be a Gentoo compiler (gcc) mis-configuration? E.g. on Debian `ffi.h` is also installed in the ABI-dependent directory, yet `gcc` finds it just fine.
Depends on your point of view. Before diving into Gentoo/Debian difference I'd like to point out that this bug was never about any package broken. But about non-intuitive headers location. In practice it does not really matter where headers hide as long as they are discovered via pkg-config interface. Now let's look at the Debian setup: $ cat a.c #include <ffi.h> $ gcc -c a.c -v #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include $ dpkg -S /usr/include/x86_64-linux-gnu/ffi.h libffi-dev:amd64: /usr/include/x86_64-linux-gnu/ffi.h Here is how the same session looks in Gentoo: $ gcc -c a.c -v #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed /usr/include a.c:1:10: fatal error: ffi.h: No such file or directory Note: Debian modifies their gcc to inject arch-specific headers search path for multiarch layout. And then installs libffi headers there so header would be discovered by default. Now, on why the things the way they are. Historically libffi is bundled with gcc as a few high-level languages (gccgo?) define C bindings in terms of libffi (but not gcc/g++). libffi library occasionally needs fixes and is technically a separate project: external users directly include <fi.h> and link to -lffi. Thus both Debian and Gentoo install libffi as a separate package. Debian went by path of mimicking bundled location. Gentoo went by a path of installing it as a typical external library. That way other compilers can also use libffi. libffi already provides a pkg-config interface for it's flags. I don't think any of distros is incorrect here. If you have a broken package please file a new bug. It is normally be trivial to fix.
*** Bug 701370 has been marked as a duplicate of this bug. ***