Re: multiarch: arch dependent header file path choice
Am 28.06.2014 19:44, schrieb Osamu Aoki:
> Hi,
>
> The path for the arch dependent header file seems to have several options.
>
> 1) /usr/include/<multiarch>/*.h
> 2) /usr/include/<multiarch>/<packagename>/*.h
> 3) /usr/lib/<multiarch>/<packagename>/include/*.h
>
> I would like to know rationale for each choice, especially between 2 and 3.
1) has the advantage that it is found in the standard include path.
3) is a cheap work around for packages installing everything
into a common prefix and then either providing symlinks in
other places or forcing users to rely on pkg-config or other
methods to find files.
You are missing 1b) /usr/include/<packagename>/*.h
There should almost be no issues for packages putting header files directly in
/usr/include or /usr/include/<multiarch>. Yes, there are some dumb tests
checking for the existence of files in a certain path which will break.
Packages installing header files in /usr/include/<packagename> usually need a
knowledge of the include path, and you'll break things just moving all header
files or a part of it to /usr/include/<multiarch>/<packagename>, because
depending packages expect that only one include path is sufficient. The solution
here is to use a fake header in /usr/include/<packagename> which includes the
appropriate header in /usr/include/<multiarch>/<packagename>. python2.7's and
python3.4's pyconfig.h file is such an example. But even here you find
configure checks to grep pyconfig.h for certain features which break which such
kind of setup ... and of course it needs updates for new architectures.
> I am sure they all are functioning choice but intriguing to see choice 3.
>
> (I was looking for the typedef of gsize in gobject header files in
> /usr/include/glib-2.0. It tool me time to find it in
> /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h)
this doesn't seem to conform to the FHS, and I assume a FHS conformant packaging
wouldn't make things worse.
> As I look around on my system, I observe followings
>
> For 1, *.h are:
> expat_config.h
> ffi.h
> ffitarget.h
one of them can live in /usr/include, however I personally prefer to install
header files in one location.
> fpu_control.h
> gmp.h
this is an example where the upstream header was patched to co-install on 32/64
bit systems not knowing about multiarch.
> ieee754.h
> lua5.1-deb-multiarch.h
> lua5.2-deb-multiarch.h
> zconf.h
>
> For 2, <packagename> are
> python3.3m
see above for the explanation for python.
> openssl
> ruby-2.0.0
> c++
this is in the standard c++ include path, so it doesn't need any special configury.
> ...
>
> For 3, <packagename> are:
> glib-2.0
> gtk-2.0
> gtk-3.0
> dbus-1.0 (dbus/dbus-arch-deps.h as *.h)
what a surprise ... I assume many upstream developers are working for distros
not using multiarch.
Matthias
Reply to: