Bugs item #1294959, was opened at 2005-09-19 03:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with /usr/lib64 builds.
Initial Comment:
This is something that's becoming more and more of a
problem as more people get systems that run both 32-bit
and 64-bit code. There are patches (926209 858809) in
the tracker to resolve this issue, I don't know exactly
what state they are in. They seem fairly old, one is
closed and one is still open.
The Fedora RPMs include the following patches for lib64
(attached).
Any thoughts on what we need to do to allow building
lib64 as a part of the standard release? Or do we just
want to wait for these terrible transition days to end
and rely on 32+64 packagers to deal with it?
Here's a short run-down of the situation: Some systems
can run both 32 and 64 bit software. On these systems
you *CAN* install a native 64-bit tool-chain, but some
people set up both 32 and 64 bit software on these
systems for compatibility. You can do 32+64 in a
couple of ways, one is to set up a "chroot" environment
for the secondary (typically 32-bit) set of libraries
and programs. The other is to run the system with
64-bit libraries in /usr/lib64 and 32-bit in /usr/lib
(because most software that needs compatibility would
be running against /usr/lib, not /usr/lib32).
It's a kludge to be sure, but if you need any legacy
software that you do not have source for, this is a way
of getting 64-bits while still retaining the ability to
run 32-bit This is not a problem for systems which
only run 64-bit code, nor is it a problem for these
32+64 systems which are running only 64-bit
distributions on them.
Thoughts?
Sean
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems with /usr/lib64 builds.
Initial Comment:
This is something that's becoming more and more of a
problem as more people get systems that run both 32-bit
and 64-bit code. There are patches (926209 858809) in
the tracker to resolve this issue, I don't know exactly
what state they are in. They seem fairly old, one is
closed and one is still open.
The Fedora RPMs include the following patches for lib64
(attached).
Any thoughts on what we need to do to allow building
lib64 as a part of the standard release? Or do we just
want to wait for these terrible transition days to end
and rely on 32+64 packagers to deal with it?
Here's a short run-down of the situation: Some systems
can run both 32 and 64 bit software. On these systems
you *CAN* install a native 64-bit tool-chain, but some
people set up both 32 and 64 bit software on these
systems for compatibility. You can do 32+64 in a
couple of ways, one is to set up a "chroot" environment
for the secondary (typically 32-bit) set of libraries
and programs. The other is to run the system with
64-bit libraries in /usr/lib64 and 32-bit in /usr/lib
(because most software that needs compatibility would
be running against /usr/lib, not /usr/lib32).
It's a kludge to be sure, but if you need any legacy
software that you do not have source for, this is a way
of getting 64-bits while still retaining the ability to
run 32-bit This is not a problem for systems which
only run 64-bit code, nor is it a problem for these
32+64 systems which are running only 64-bit
distributions on them.
Thoughts?
Sean
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com