Re: how to handle architecture dependent headers in subdirectories
Matthias Klose <doko@debian.org> writes:
> There are some issues when you do have an architecture dependent header
> file which needs to be in the multiarch specific include directory. If
> the header file is directly located in /usr/include, then moving it to
> /usr/include/<multiarch-tuple> usually is not a problem (except for
> quoting issues as found in the packaging for libreoffice). The
> compilers (checked here GCC and clang) do include the multiarch include
> path as a path for system includes too.
> However there are some issues when you do need to split the header files
> into different locations. Seen that with python2.7 and python3.3 in
> experimental, however I think it is a concern for packages like openssl
> as well.
> Looking at python in experimental (having the architecture independent
> headers in /usr/include and the architecture dependent headers in
> /usr/include/<multiarch-tuple>) you have some build failures.
> For the python case:
> - moving all the headers to the multiarch include path doesn't work,
> because configure tests fail which assume the include directory
> a direct subdirectory of <prefix>.
Why not just fix this bug instead? That's what I did for OpenAFS. I
think it's more robust than trying to split the header files apart.
This is probably a sign of badly-written configure probes anyway, since it
implies that configure is not using the compiler to test headers and is
instead poking about on the file system.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: