On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote:
In article <1369986770.4119.43.camel@homebase>, Paul Smith <paul@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.