Hi folks,
I always thought that headers go into %{_includedir}. Can someone please clarify if this is really a bug or not?
https://bugzilla.redhat.com/show_bug.cgi?id=727301
On Wed, 08 Aug 2012 14:16:54 +1000, Ankur Sinha wrote:
Hi folks,
I always thought that headers go into %{_includedir}. Can someone please clarify if this is really a bug or not?
It's a bug in the same way it would be a bug if the headers were stored below %_bindir, %_mandir, %_sysconfdir or dirs other than %_includedir.
It may be worth a shot to contact libffi upstream about that unless it's just the Fedora package that uses %_libdir for the headers.
[The comment about pkg-config --cflags is ridiculous. Sure, that command can be used to retrieve the include path options, and without pkg-config it would be difficult to _guess_ the versioned subdir, but nevertheless headers don't belong into %_libdir.]
Le 08/08/2012 10:53, Michael Schwendt a écrit :
It's a bug in the same way it would be a bug if the headers were stored below %_bindir, %_mandir, %_sysconfdir or dirs other than %_includedir.
I mostly agree, but... Where arch specific header should go ?
$ find /usr/lib64 -name *.h | wc -l 393
most are perl and qt headers, but some gnome package also put their header here.
Currently we use some workaround (see mysql or libzip) /usr/include/mysql/my_config.h /usr/include/zipconf.h
(libzip upstream also use %{_libdir} for zipconf.h)
So, I think, %{_libdir}/foo/include is not a so bad solution.
Remi.
On Wed, 08 Aug 2012 11:09:15 +0200, Remi Collet wrote:
It's a bug in the same way it would be a bug if the headers were stored below %_bindir, %_mandir, %_sysconfdir or dirs other than %_includedir.
I mostly agree, but... Where arch specific header should go ?
%{_includedir}/something-target-cpu-dependent/
and have $(pkg-config --cflags) return that directory. With a versioned topdir, one example would be:
/usr/include/libname-1.0/${ARCH}/libname/*.h
$ pkg-config --cflags libname-1.0 -I/usr/include/libname-1.0/${ARCH}
#include <libname/….h>
It could even be the upstream installer doing that, with arch-dependent conditionals in platform-independent headers including the arch-specific bits from subdirs.
/usr/include/libname/*.h -> /usr/include/libname/${ARCH1}/*.h -> /usr/include/libname/${ARCH2}/*.h
And if it weren't a versioned topdir, you could even access the header files without extending search path list, since /usr/include is a default search path whereas %_libdir is not.
$ find /usr/lib64 -name *.h | wc -l 393
most are perl and qt headers, but some gnome package also put their header here.
Qt also stores (or used to store) executables somewhere below %_libdir, using it as some sort of home/root dir. Not a suitable counter-example to prove anything other than that some more headers are misplaced.
Currently we use some workaround (see mysql or libzip) /usr/include/mysql/my_config.h /usr/include/zipconf.h
(libzip upstream also use %{_libdir} for zipconf.h)
So, I think, %{_libdir}/foo/include is not a so bad solution.
For multiarch, it's a work-around only, a lazy one, as %_libdir is a quick way to get a directory that differs by arch.
On Wed, 2012-08-08 at 10:53 +0200, Michael Schwendt wrote:
It may be worth a shot to contact libffi upstream about that unless it's just the Fedora package that uses %_libdir for the headers.
I just peeked into the spec[1]. Looks like this is how upstream places the header.
Simone has already commented[2], requesting maintainer to move the header to %{_includedir} and update the pc file.
[1] http://pkgs.fedoraproject.org/cgit/libffi.git/tree/libffi.spec?h=f18&id=...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=727301#c6
packaging@lists.fedoraproject.org