Matthias Klose <d...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bocog11m....@windlord.stanford.edu
