[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