[Python-Dev] Problem building Python 2.7.5 with separate sysroot
Paul Smith
paul at mad-scientist.net
Fri May 31 13:35:29 CEST 2013
On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote:
> In article <1369986770.4119.43.camel at homebase>,
> Paul Smith <paul at mad-scientist.net> wrote:
>
> > Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14)
> > system, but using a different sysroot (that is, a separate
> > <d>/usr/include, <d>/usr/lib, etc., not the real one for my system).
>
> This list is for the development of Python itself, not about using or
> installing it. Python-list (AKA comp.lang.python) is the right list to
> ask such questions. That said ...
>
> > However, I'm having serious problems building modules such as fcntl,
> > etc. Looking at the output from the makefile, I can see that somehow,
> > someone is forcibly adding "-I/usr/include/x86_64-linux-gnu" to the link
> > line: [...]
>
> ... include file and library file selections for building standard
> library modules are handled by the top-level setup.py file in the source
> tree. That's where /usr/local/... is added and chances are that the
> above header is being added by add_gcc_paths() in setup.py.
Yes, thank you.
It seems to me (keeping with the theme of this mailing list) that the
add_multiarch_paths() function in setup.py is not right.
The first step, which asks the compiler about multi-arch, is OK because
it's using my alternate compiler which reports no multiarch.
But then it proceeds to run the local host version of dpkg-architecture.
I see that it adds the -t flag if cross-compiling, which I'm not, but
even that is not fixing the issue.
If you're building on a system which is Debian derived with multi-arch
support you will ALWAYS have your local "/usr/include" (plus some
multiarch suffix) -- and '/usr/lib' + multiarch -- added to your include
and lib paths; this is not good. My case may be unusual but even in a
more formal cross-compilation environment it's not good to
add /usr/include/..., or base such a decision on the behavior of the
_build_ system.
More information about the Python-Dev
mailing list