[Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1

noreply@sourceforge.net noreply@sourceforge.net
Wed, 18 Apr 2001 22:03:14 -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: Closed
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: 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