This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2012年05月12日 16:40 by pitrou, last changed 2022年04月11日 14:57 by admin.
| Files | ||||
|---|---|---|---|---|
| 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 (6) | |||
|---|---|---|---|
| msg160478 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2012年05月12日 16:40 | |
setup.py 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 setup.py 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. |
|||
| msg380458 - (view) | Author: Irit Katriel (iritkatriel) * (Python committer) | Date: 2020年11月06日 17:05 | |
Was this resolved by the fix for https://bugs.python.org/issue32059? |
|||
| msg380492 - (view) | Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) | Date: 2020年11月07日 04:19 | |
No. setup.py still contains several hardcoded paths with "lib" (e.g. "/usr/local/lib", "/usr/lib/termcap"). There are also some places in setup.py which check both "lib64" and "lib", but such checks can possibly return incorrect results on multilib systems (when a library happens to be available for another ABI (32-bit vs 64-bit) but not ABI for which Python is being built). |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:30 | admin | set | github: 58996 |
| 2020年11月07日 10:02:02 | iritkatriel | set | versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.2, Python 3.3 |
| 2020年11月07日 04:19:06 | Arfrever | set | messages: + msg380492 |
| 2020年11月06日 17:05:13 | iritkatriel | set | nosy:
+ iritkatriel messages: + msg380458 |
| 2012年07月08日 04:44:29 | ned.deily | set | nosy:
+ ned.deily messages: + msg164965 |
| 2012年07月08日 00:24:12 | doko | set | files:
+ setup.diff messages: + msg164956 |
| 2012年07月07日 17:47:47 | pitrou | set | nosy:
+ doko |
| 2012年05月14日 10:47:38 | jcea | set | nosy:
+ jcea |
| 2012年05月12日 17:02:47 | Arfrever | set | nosy:
+ Arfrever messages: + msg160483 |
| 2012年05月12日 16:40:42 | pitrou | create | |