On Wed, Jan 16, 2013 at 03:28:53PM -0800, Russ Allbery wrote: > 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? Primarily, because the bug needs to be fixed in a large number of separate upstream sources, and until this is done (which is unlikely to happen during the release freeze, even in experimental), improved multiarch support for python headers (which is rather important for cross-buildability of Debian) would be blocked. > 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. If all upstream sources were using sensible configure checks (i.e., via pkg-config), then /either/ approach to distributing the headers would work fine. The perverse world we live in gives us instead a range of upstream sources with mutually opposed sets of incorrect build-time checks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature