Title: only adds /prefix/lib, not /prefix/lib64
Type: behavior Stage: patch review
Components: Build Versions: Python 3.2, Python 3.3
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, dmalcolm, doko, jcea, ned.deily, pitrou
Priority: low Keywords: patch

Created on 2012-05-12 16:40 by pitrou, last changed 2012-07-08 04:44 by ned.deily.

File name Uploaded Description Edit
setup_lib64.patch pitrou, 2012-05-12 16:40 review
setup.diff doko, 2012-07-08 00:24 review
Messages (4)
msg160478 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-05-12 16:40 adds <prefix>/lib to the list of directories where libraries are looked for, but not <prefix>/lib64. Patch attached.
msg160483 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2012-05-12 17:02
It would be better to fix issue #1294959 and use os.path.join(sys.prefix, sys.libdir).
IIRC some mips architectures need "/usr/lib32", while x32 architecture needs "/usr/libx32".
msg164956 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2012-07-08 00:24
using sys.maxsize isn't safe for cross builds. it should at least guarded by 'if not cross_compiling'.

I still think that the preferred way to get the library dirs is to ask the compiler (patch attached), however this will add "incompatible" library dirs as well, at least for multilib'd gcc builds, and leading to linker warnings when building the extensions. At least when using gcc this should address the issue finding the lib32 and libx32 dirs.
msg164965 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-07-08 04:44
Also OS X universal builds have many of the characteristics of a cross-build.  In particular, one executable (like the python interpreter) can contain both 32-bit and 64-bit architecture files.  So tests for 32-bit vs 64-bit at build time using the running compiler's arch are problematic.  Another issue is the support for building with an OS X SDK.  Basically, all /usr include and lib file paths used for searching in need to be prefixed by the SDK path if configured.  There are some holes in this right now.  I plan to fix them soon; it would better to have this issue resolved and applied first.
Date User Action Args
2012-07-08 04:44:29ned.deilysetnosy: + ned.deily
messages: + msg164965
2012-07-08 00:24:12dokosetfiles: + setup.diff

messages: + msg164956
2012-07-07 17:47:47pitrousetnosy: + doko
2012-05-14 10:47:38jceasetnosy: + jcea
2012-05-12 17:02:47Arfreversetnosy: + Arfrever
messages: + msg160483
2012-05-12 16:40:42pitroucreate