[Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 22 Apr 2001 10:56:02 -0700
Patches item #413011, was updated on 2001-04-02 00:08
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port to UnixWare 7.1.x for Python 2.1
Initial Comment:
The attached file contains patches and files needed to
allow Python-2.1(b2a) to be configured and compiled
successfully on a SCO UnixWare 7.1.x system using the
SCO Universal Development Kit (UDK). The compiled
Python-2.1(2ba) executable did not fail any tests
except for the atan2(0,1) math test. UnixWare returns
pi instead of the expected 0.0 result.
The Python-2.1 on UnixWare 7.1.x will have a shared
Python-2.1 library, have dynamically loadable modules,
and support for theads.
The attached tar file (Python-2.1b2a-UW7.tar.gz)
contains a README file describing the details of the
changes.
The MD5 checksum for the attached file is:
46704c26064c41f195decccd60adffab
Billy G. Allie <Bill.Allie@mug.org>
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2001-04-22 10:56
Message:
Logged In: YES
user_id=21627
1. Instead of requiring administrators to set LD_RUN_PATH,
configure should automatically set all proper options,
-R<prefix>/lib in this case.
However, I still doubt that using a shared library offers
advantages:
a. According to my measurements, linking python statically
brings a 50% speed-up in startup time when *not* using
shared libraries. This is because:
I. fewer shared libraries have to be located and loaded
II. the LD_RUN_PATH is shorter, so fewer directories have to
be searched
III. The main part of the interpreter is not compiled with
-KPIC; PIC code is typically slower since EBX is not
available to the optimizer.
The size of the executable is pointless; the system has to
load libpython21.so in the shared case, which is 800k
b. There is typically only a single executable relying on
libpython.so, so the administrative overhead of replacing
the library is the same as replacing the executable. There
may be applications to a shared libpython, but given the
pain that this causes, that should be a configuration
option, and off by default. As an option, it should equally
apply to all ELF-based systems, at a minimum.
3. crti and crtn are needed in *every* shared library,
otherwise, constructors don't work. Use -# to see how the
linker is invoked for -G, to notice that it not only links
crti/crtn, but also libcrt.
4. I just checked that supporting -lpthread is required by
Single Unix from conforming implementations, see
http://www.opengroup.org/onlinepubs/007908799/xcu/c89.html
So I'm surprised your UnixWare copy does not support it.
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-04-21 15:38
Message:
Logged In: YES
user_id=8500
1. when compiling, you need to set LD_RUN_PATH to the
directory that will contain the shared library. This is or
should be standard operating procedure whenerve compiling
programs that use shared libraries. Doing this prevents
having to have LD_LIBRARY_PATH set when executing the
program. For my use, I set
LD_RUN_PATH=/usr/local/lib:/usr/local/pgsql/lib. Since I
know I will be accessing PostgreSQL from python, I let
python know that I will be using shared libraries contained
in /usr/local/pgsql/lib. You would only need to set
LD_LIBRARY_PATH=. when first building and testing python.
The advantage of using a shared library includes, but is not
limited to:
a. Faster start-up times once the library is loaded into
memory. Loading a 5k executable is faster than loading a
760k executable.
b. Executables and other shared modules will not have to
be recompiled if a fix needs to be made to one of the
objects in the shared library (that does not invole change
the parameter or return value of the object).
2. But the options do something - they make explicit the
intent of the code. Also, what happens if the defaults
change (not likely, I must admit, but possiple). Rather,
then make matenance more difficult, I believe that it makes
it easier, since the true intent is clear. But, I fear were
are treading into the realm of philosopy and the "way to do
things", where everyone has an (a differing, but equally
valid) opinion,
3. I never said that they were not needed, only that they
are included in the program using the shared library, not
the library itself.
4. I have he save compiler version, but my cc(1) does not
mention the -Kpthread flag. I will check into this and will
change the UnixWare build to use it. It would appear to
alieviate the need to implement the fork1() call.
As to rolling out the patch, I disagree. Having the shared
library does have some addvantages, and the proper
setting/use of LD_RUN_PATH and LD_LIBRARY_PATH can be
handled with a platform specific FAQ.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 06:18
Message:
Logged In: YES
user_id=21627
Dear Mr Allie,
0. cc -V reports
Optimizing C Compilation System (CCS) 4.0 10/23/00 (UDK FS
7.1.1b)
1. Support for threads on UnixWare was there before the
patch was applied. I don't think the patch really supports
generating a shared Python library, though. When I compile
Python 2.1, I get, after the first stage build,
PYTHONPATH= ./python ./setup.py build
dynamic linker : ./python : could not open libpython2.1.so
*** Error code 137 (bu21)
The cause is that the location of libpython2.1.so is not
known to the dynamic linker. So your port does not work out
of the box, the user is required to set LD_LIBRARY_PATH.
This is precisely the reason why no other Unix port uses a
shared libpython: it only causes problems, and gives no
advantages. Why do you want libpython as a shared library?
2. It simplifies maintenance, since maintainers can reason
whether some option needs to be carried over to a future
release of the same system or a slightly similar system.
Options that don't do anything cause confusion.
3. crti.o and crtn.o are certainly needed, they provide the
.init and .fini section, and arrange to execute the .ctor
and .dtor sections. See also bugreport 417491.
5. The mentioned compiler does support -Kpthread, cc(1)
reports
pthread
Causes the same effect as -Kthread, except that in
addition POSIX threads semantics are enabled at runtime
for the fork(2), raise(3C), thr_exit(3thread), and
pthread_exit(3pthread) calls. -lpthread is an acceptable
synonym for -Kpthread.
Therefore, even though there is no libpthread on the system,
-lpthread can still be passed to the compiler, and the
standard pthread detection routines in Python will work
correctly.
So in short, I think the entire patch should be backed out,
and any remaining problems should be fixed differently.
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-04-18 22:03
Message:
Logged In: YES
user_id=8500
loewis,
First, a question. Are you using the SCO UDK compiler to
compile Python? The UDK is the target compiler addressed by
these patches (see the README file included with the patch).
1. This patch added support for using threads and to
generate a shared Python library.
2. There is no reason to not explicitly specify the
argument that are the defaults either.
3. I'll cede the point about using cc to link the shared
modules, but the shared library does not need crti.o and
crtn.o. They would be linked into the executable that
references the shared library.
4. Perhaps, but my goal was to get UnixWare to compile with
thread support and using shared libraries. I do not have
access to those other systems, so I could not make chages to
the way configure handles them (I wouldn't be able to test
those changes). If others would like to make those changes,
I would be willing to work with them to come up with a
uniform way of teating the similar systems.
5. The UnixWare UDK requires the use of -Kthread to control
the (correct) linking of the thread libraries. Using
-lthread is specifically warned against. There is no
-Kpthread option nor is there a libpthread library. The
-Kthread option will load the POSIX thread routines if they
are used.
To reiterate, my goal was to be able to compile on UnixWare
using shared libraries and including supprot for threads. I
also wanted to do this in a manner that would not affect how
other systems were handled. Again, I only have a UnisWare
system on whick to build and test the changes.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-04-13 15:04
Message:
Logged In: YES
user_id=21627
Even though this patch has been applied, I'd like to express
my concerns about it.
First, Python 2.1b2 was compiling correctly on UnixWare even
without this patch, atleast since configure.in 1.212. So
what specific problem had been corrected with this patch?
Next, the patch seems to overspecify compiler and linker
options. Eg. -dy is the default, so there is no need to
explicitly specify it.
Also, in many cases, using cc to link executables and
libraries is better than using ld, since cc will
automatically pass missing options, object files, and
libraries. E.g. with your options, crti.o and crtn.o won't
be included into the shared libraries, but should be (See
Notices in ld(1)).
The patch adds code specific to UnixWare which would apply
to many other systems (Solaris, Linux, ReliantUnix), and it
would be good if these systems would be treated uniformly.
E.g. it creates libpython as a shared library. Why only on
Unixware, why not on Solaris or Linux?
Likewise, why the special casing on threads? There are other
systems (SysV variants) that also support -Kthread, so there
should be a test whether the compiler supports the flag, not
whether the system is Unixware. Also, shouldn't this be
-Kpthread, not -Kthread? Finally, isn't just using -lpthread
enough?
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-04-11 14:19
Message:
Logged In: YES
user_id=8500
Every thing looks fine (as far as I can tell).
Thanks.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 14:00
Message:
Logged In: YES
user_id=6380
Thanks, that's much better! Applied now.
(Please check that I checked everything in... :-)
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-04-11 13:13
Message:
Logged In: YES
user_id=8500
here is the MD5 checksum for the corrected patch:
MD5 (Python-2.1b2a.UW7.p2.tar.gz) =
62941fcbdd0d4272767b52b2a42d9388
----------------------------------------------------------------------
Comment By: Billy G. Allie (ballie01)
Date: 2001-04-11 13:08
Message:
Logged In: YES
user_id=8500
Here is a corrected patch file. I pulled the latest files
from CVS and patched those. These should be fine.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 14:47
Message:
Logged In: YES
user_id=6380
Something went wrong with tabs and spaces in your patch; it
appears the version of the sources you diffed against had
some tabs
replaced with spaces or vice versa.
Unless yu can supply a correct context diff really fast, I
won't be able to include this patch in Python 2.1. I don't
have the time to review every change and to manually apply
the chunks that patch rejects. (Esp. configure.in).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470