Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 643582 - dev-libs/libffi-3.2.1: Installs include files to /usr/lib64/libffi-3.2.1/include
Summary: dev-libs/libffi-3.2.1: Installs include files to /usr/lib64/libffi-3.2.1/include
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 701370 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-05 16:59 UTC by William L. Thomson Jr.
Modified: 2019-11-28 08:00 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William L. Thomson Jr. 2018-01-05 16:59:27 UTC
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.
Comment 1 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-06 11:25:02 UTC
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.
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-06 12:22:00 UTC
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
...
Comment 3 Larry the Git Cow gentoo-dev 2018-01-06 13:03:23 UTC
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(-)}
Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-06 13:37:01 UTC
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
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-06 13:51:11 UTC
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.
Comment 6 William L. Thomson Jr. 2018-01-06 17:54:53 UTC
Thanks I guess its all moot so long as using pkg-config. Thanks again sorry for the waste of time.
Comment 7 Dima Pasechnik 2019-01-30 14:49:38 UTC
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.
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2019-01-30 20:53:32 UTC
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.
Comment 9 Sergei Trofimovich (RETIRED) gentoo-dev 2019-11-28 08:00:04 UTC
*** Bug 701370 has been marked as a duplicate of this bug. ***