[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: lib64_tests-2.py: Updated test for PR 18381. It now uses sys.platlibdir and it tests also Makefile LIBPL variable. -- Added file: https://bugs.python.org/file48962/lib64_tests-2.py ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-24871: "freeze.py doesn't work on x86_64 Linux out of the box". > On 64-bit Linux freeze.py uses lib instead of lib64 when constructing > path to Makefile etc. Using sysconfig fixes this issue. -- ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: > Why "sys.python_libdir"? Isn't that too public? A lot of similar > path-related info is in sysconfig; why shouldn't it be there? I replied in a previous comment: "Matthias Klose asked to not add another sys attribute, but Jan Matějek explained that the

[issue1294959] Problems with /usr/lib64 builds.

Petr Viktorin added the comment: Why "sys.python_libdir"? Isn't that too public? A lot of similar path-related info is in sysconfig; why shouldn't it be there? How does "sys.python_libdir" work on other platforms? -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Change by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: Links on Debian Multiarch: * https://wiki.debian.org/Multiarch/HOWTO * https://lwn.net/Articles/711199/ -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: lib64_tests.py: test suite hardcoded for Fedora, SuSE and PR 18381 with --with-python-libdir=lib64. I wrote it to help me to understand differences between Fedora, SuSE and PR 18381. On Fedora, the test fails because we have an additional patch on distutils

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: Ooops, SuSE has 2 patches. SuSE currently uses these patches for lib64 in the Python 3 package: (1) https://build.opensuse.org/package/view_file/devel:languages:python:Factory/python3/F00102-lib64.patch?expand=1 (2)

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: SuSE currently uses this patch for lib64 in the Python 3 package: https://build.opensuse.org/package/view_file/devel:languages:python:Factory/python3/F00102-lib64.patch?expand=1 -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Miro Hrončok added the comment: > > Also note that the extension modules have archful suffix, so they will not > > collide in $HOME, unless they are installed as name.so. > > Yeah, it seems like pip install adopted Debian multiarch naming: > "x86_64-linux-gnu" triplet in

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: > posix_user: > > * stdlib: '~/.local/lib64/python3.9' > * platstdlib: '~/.local/lib64/python3.9' > * platlib: '~/.local/lib64/python3.9/site-packages' Honestly, I have no idea how posix_user is used. ~/.local/lib64/ directory doesn't exist on my work

[issue1294959] Problems with /usr/lib64 builds.

Miro Hrončok added the comment: Also note that the extension modules have archful suffix, so they will not collide in $HOME, unless they are installed as name.so. -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Matej Cepl added the comment: > posix_user: > > * stdlib: '~/.local/lib64/python3.9' > * platstdlib: '~/.local/lib64/python3.9' > * platlib: '~/.local/lib64/python3.9/site-packages' I am still not sure about the this one. I know that I have mentioned a possibility of multiplatform $HOME on

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: Default with prefix=/usr: * posix_prefix: * stdlib: '/usr/lib/python3.9' * platstdlib: '/usr/lib/python3.9' * platlib: '/usr/lib/python3.9/site-packages' * posix_user: * stdlib: '~/.local/lib/python3.9' * platstdlib: '~/.local/lib/python3.9' *

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: Summary: * This issue is mostly about pushing a 16-years old patch from Fedora and SuSE to Python upstream. Other Linux distributions use different solutions to support multiple architectures in the same filesystem. For example, Debian and Ubuntu uses

[issue1294959] Problems with /usr/lib64 builds.

miss-islington added the comment: New changeset ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458 by Miss Islington (bot) in branch '3.8': bpo-21016: pydoc and trace use sysconfig (GH-18476) https://github.com/python/cpython/commit/ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458 --

[issue1294959] Problems with /usr/lib64 builds.

miss-islington added the comment: New changeset ca133e53fafdec1aa77613fcb7558deed959383f by Miss Islington (bot) in branch '3.7': bpo-21016: pydoc and trace use sysconfig (GH-18476) https://github.com/python/cpython/commit/ca133e53fafdec1aa77613fcb7558deed959383f -- nosy:

[issue1294959] Problems with /usr/lib64 builds.

Change by miss-islington : -- pull_requests: +17856 pull_request: https://github.com/python/cpython/pull/18483 ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

Change by miss-islington : -- pull_requests: +17854 pull_request: https://github.com/python/cpython/pull/18482 ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: New changeset 4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd by Victor Stinner in branch 'master': bpo-21016: pydoc and trace use sysconfig (GH-18476) https://github.com/python/cpython/commit/4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd --

[issue1294959] Problems with /usr/lib64 builds.

Change by STINNER Victor : -- pull_requests: +17846 pull_request: https://github.com/python/cpython/pull/18476 ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

Change by STINNER Victor : -- versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Change by Carlos Velasco : -- nosy: +carlos.velasco ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-21016: "trace: $prefix and $exec_prefix improperly replaced on Fedora". -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-18092 ("Python 2.7.5 installation broken on OpenSuse 12.2") as a duplicate of this issue. -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-14791: "setup.py only adds /prefix/lib, not /prefix/lib64". -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-34032 as a duplicate of this issue. It has an open PR written by Matěj Cepl (OpenSUSE): PR 8068. It looks similar to PR 3698. -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-34058 "Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/": OpenSUSE and Centos are mentioned as being impacted. --

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-15631 as a duplicate of this issue. -- ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I closed bpo-858809 as a duplicate of this issue. -- ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Change by STINNER Victor : -- pull_requests: +17757 pull_request: https://github.com/python/cpython/pull/18381 ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

Change by Matej Cepl : -- versions: +Python 3.8, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

Change by Matej Cepl : -- nosy: +mcepl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

Change by Charalampos Stratakis : -- pull_requests: +11696, 11698 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue1294959] Problems with /usr/lib64 builds.

Change by Charalampos Stratakis : -- pull_requests: +11696, 11697 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue1294959] Problems with /usr/lib64 builds.

Change by Charalampos Stratakis : -- pull_requests: +11696 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

Change by Eitan Adler : -- nosy: +eitan.adler ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Change by Bob Vincent : -- nosy: +pillarsdotnet ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Change by Miro Hrončok : -- nosy: +encukou, hroncok ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose added the comment: the patch looks ok. was it tested on a Debian or Ubuntu system to produce the same layout with this patch and without the new configure option? -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Charalampos Stratakis added the comment: Pinging here. Is there some way to push the issue forward? -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

Changes by jan matejek : -- pull_requests: +3682 stage: -> patch review ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw added the comment: On Jan 18, 2017, at 03:57 PM, Matthias Klose wrote: >I don't think we need a PEP for this Correct. Generally we don't need PEPs for build system changes. -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose added the comment: I don't think we need a PEP for this, however I would like to name the new macro libsubdir, or sublibdir, to make it clear it's just the libdir component. Or make the value absolute, like it already is for libdir ... --

[issue1294959] Problems with /usr/lib64 builds.

jan matejek added the comment: Attached is a patch that I'd like to propose for inclusion. It introduces a new configure option "--with-custom-platlibdir=", which defaults to `basename $libdir`. This is converted to makefile variable "platlibdir", which is used in getpath.c to generate value

[issue1294959] Problems with /usr/lib64 builds.

Charalampos Stratakis added the comment: The downstream patch we currently use in Fedora [0]. [0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/plain/00102-lib64.patch -- nosy: +cstratak ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue1294959] Problems with /usr/lib64 builds.

jan matejek added the comment: at this again, when porting SUSE patches to 3.6.0 :) ( :( ) Last time there was a discussion, Barry suggested using sysconfig variables to find the proper libdir. Trouble is, to fill out the variables, sysconfig itself uses two sources: a) compiled-in

[issue1294959] Problems with /usr/lib64 builds.

Mark Lawrence added the comment: Also see #15631 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list

[issue1294959] Problems with /usr/lib64 builds.

Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Mark Lawrence added the comment: Is there agreement on what needs doing here? I'd like to see this into 3.5 before it reaches its 10th birthday :) -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw added the comment: Is this issue still relevant? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list

[issue1294959] Problems with /usr/lib64 builds.

jan matejek added the comment: Yes. We still have a patch for two things: 1. fix setup.py script to look for libraries in correct (lib64) prefixes, and 2. fix values returned from sysconfig, to reflect that python resides in lib64 $prefix/lib is hardcoded in many places. Lib64 is probably not

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose added the comment: the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu. At least the configure check should check for lib64 as a directory and not a symlink, and only then default to lib64. two other issues with the patch: - I would like to see any new

[issue1294959] Problems with /usr/lib64 builds.

jan matejek added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 7.11.2013 16:56, Matthias Klose napsal(a): Matthias Klose added the comment: the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu. This patch is provided for reference only - it works for us at

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Nov 07, 2013, at 04:05 PM, jan matejek wrote: - I would like to see any new OS-dependent locations in the sysconfig module, not the sys module. how would you propose to put the value into sysconfig in the

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw added the comment: On Nov 07, 2013, at 03:40 PM, jan matejek wrote: To reiterate, our current solution is to introduce sys.lib (and sys.arch, but that is never used anymore) that is either lib or lib64, and use this in place of the string lib wherever appropriate. We find the

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose added the comment: I disagree about sys.implementation. It's useless and wrong for cross builds. Please use sysconfig instead. What sysconfig is maybe missing is a set of variables which you can rely on. -- ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Arfrever Frehtes Taifersar Arahesis added the comment: configure.ac should accept an option, which allows to set any custom libdir. Examples (architecture: libdir) in Gentoo: x32: libx32 mips o32: lib mips n32: lib32 mips n64: lib64 -- ___

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw added the comment: On Nov 07, 2013, at 04:56 PM, Matthias Klose wrote: I disagree about sys.implementation. It's useless and wrong for cross builds. Please use sysconfig instead. What sysconfig is maybe missing is a set of variables which you can rely on. Agreed that sysconfig

[issue1294959] Problems with /usr/lib64 builds.

Changes by Catalin Iacob iacobcata...@gmail.com: -- nosy: +catalin.iacob ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Marc-Andre Lemburg m...@egenix.com added the comment: Éric Araujo wrote: Éric Araujo mer...@netwok.org added the comment: On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote: no, it looks for headers and libraries in more directories. But really, this whole testing for paths is wrong.

[issue1294959] Problems with /usr/lib64 builds.

Éric Araujo mer...@netwok.org added the comment: On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote: no, it looks for headers and libraries in more directories. But really, this whole testing for paths is wrong. Just use the compiler to search for headers and libraries, no need to check

[issue1294959] Problems with /usr/lib64 builds.

Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: I currently think that sys.libdir should be only basename of libdir (e.g. lib or lib64) to allow to easily use it with something else than sys.prefix. -- ___ Python

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: Here's a fix that works for me on Ubuntu 11.04. -- hgrepos: +12 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Changes by Barry A. Warsaw ba...@python.org: Added file: http://bugs.python.org/file21453/a9b05b89ea39.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Changes by Barry A. Warsaw ba...@python.org: Removed file: http://bugs.python.org/file21453/a9b05b89ea39.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Changes by Barry A. Warsaw ba...@python.org: Added file: http://bugs.python.org/file21454/a4dcae4cd033.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: I should note that I'd love to backport this to Python 3.2, 3.1, 2.7 and 2.6 since none of them can build entirely now on multiarch systems. Since it only affects search order in the build process, one could argue that it's not a new

[issue1294959] Problems with /usr/lib64 builds.

Antoine Pitrou pit...@free.fr added the comment: Barry: does it allow to install Python into /usr/lib/whateverarch, or is it just a partial fix for something slightly unrelated to this issue? -- nosy: +pitrou ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: A proper fix is to introduce sys.libdir, which would be controllable by --libdir=${value} option of `configure`. If --libdir=${value} is not passed, then sys.libdir would default to sys.prefix + /lib. sysconfig,

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: On Mar 29, 2011, at 07:28 PM, Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: Barry: does it allow to install Python into /usr/lib/whateverarch, or is it just a partial fix for something slightly unrelated to this

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: I retract my patch for this bug because the issue described here is actually different than the one I want to fix. See issue 11715 for the problem of building Python on multiarch Debian and Ubuntu (e.g. Ubuntu 11.04). --

[issue1294959] Problems with /usr/lib64 builds.

Changes by Barry A. Warsaw ba...@python.org: Removed file: http://bugs.python.org/file21454/a4dcae4cd033.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: On Mar 29, 2011, at 07:38 PM, Arfrever Frehtes Taifersar Arahesis wrote: A proper fix is to introduce sys.libdir, which would be controllable by --libdir=${value} option of `configure`. If --libdir=${value} is not passed, then sys.libdir would

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose d...@debian.org added the comment: heh, that's easy, just add the multiarch id to the extension name ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose d...@debian.org added the comment: On 29.03.2011 21:28, Antoine Pitrou wrote: Barry: does it allow to install Python into /usr/lib/whateverarch, no, it looks for headers and libraries in more directories. But really, this whole testing for paths is wrong. Just use the compiler

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: On Mar 29, 2011, at 10:12 PM, Matthias Klose wrote: no, it looks for headers and libraries in more directories. But really, this whole testing for paths is wrong. Just use the compiler to search for headers and libraries, no need to check

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: On Mar 29, 2011, at 10:11 PM, Matthias Klose wrote: heh, that's easy, just add the multiarch id to the extension name ;-) Clever! :) -- ___ Python tracker rep...@bugs.python.org

[issue1294959] Problems with /usr/lib64 builds.

Barry A. Warsaw ba...@python.org added the comment: Please note another aspect of this problem will bite all Python developers on Ubuntu 11.04. With the introduction of multiarch, not all stdlib Python extension modules can be built out of the box, as seen here:

[issue1294959] Problems with /usr/lib64 builds.

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing

[issue1294959] Problems with /usr/lib64 builds.

Changes by Andy Buckley a...@insectnation.org: -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___

[issue1294959] Problems with /usr/lib64 builds.

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- type: - behavior versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959

[issue1294959] Problems with /usr/lib64 builds.

Changes by Éric Araujo mer...@netwok.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing

[issue1294959] Problems with /usr/lib64 builds.

Éric Araujo mer...@netwok.org added the comment: If I understand correctly, using lib32 or lib64 is a kludge. Debian and Ubuntu want to come up with a better way to do this: http://wiki.debian.org/ReleaseGoals/MultiArch https://wiki.ubuntu.com/MultiarchSpec Kind regards. -- nosy:

[issue1294959] Problems with /usr/lib64 builds.

Akira Kitada akit...@gmail.com added the comment: I think this is duplicate of issue858809. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Matthias Klose d...@debian.org added the comment: both patches assume that everybody uses lib64 for 64bit libs, which is not true for Debian/Ubuntu. Even the FHS doesn't mandate the use of lib64. -- nosy: +doko ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

jan matejek jmate...@suse.cz added the comment: well in our patch, at least, the directory is governed by sys.lib which is defined through configure. i don't understand the configure language well enough, but i'd assume that making it parametrized isn't too hard? --

[issue1294959] Problems with /usr/lib64 builds.

jan matejek jmate...@suse.cz added the comment: for completenes, here's a patch that's in use in SUSE. it's advantage over Fedora's is that it works on both 32bit and 64bit installs -- Added file: http://bugs.python.org/file14726/Python-2.6.2-multilib.patch

[issue1294959] Problems with /usr/lib64 builds.

Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing

[issue1294959] Problems with /usr/lib64 builds.

Akira Kitada akit...@gmail.com added the comment: 3rd party C modules are put in site-packages, so just having importer of 64-bit python look at lib64-dynload is not enough for solving this. To work around this problem, I did some hacks on my local Python to look at lib and lib64. It worked,

[issue1294959] Problems with /usr/lib64 builds.

Akira Kitada akit...@gmail.com added the comment: Similar problem report: http://bugs.python.org/issue1019715 -- nosy: +akitada ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___

[issue1294959] Problems with /usr/lib64 builds.

Alexander Belopolsky [EMAIL PROTECTED] added the comment: Can someone update the priority so that this is looked at before the 2.6 release? -- nosy: +belopolsky _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1294959

[issue1294959] Problems with /usr/lib64 builds.

Alexander Belopolsky [EMAIL PROTECTED] added the comment: Placing the entire library tree in /usr/lib64 is wasteful on dual 32/64bit installation, but placing just the C modules there is contrary to python import logic and may cause problems to relative imports. I have suggested what I

[issue1294959] Problems with /usr/lib64 builds.

Changes by Ignacio Vazquez-Abrams: -- nosy: +ivazquez _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1294959 _ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294959] Problems with /usr/lib64 builds.

Christian Heimes added the comment: The problem with 64 bit builds should be discussed before we release 2.6. Another bug day topic. -- components: +Build -None keywords: +patch nosy: +tiran versions: +Python 2.6, Python 3.0 _ Tracker [EMAIL