[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to handle architecture dependent headers in subdirectories

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

Reply to: