[Patches] [ python-Patches-709178 ] remove -static option from cygwinccompiler

SourceForge.net noreply@sourceforge.net
Thu, 10 Apr 2003 09:19:17 -0700


Patches item #709178, was opened at 2003-03-24 17:55
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: John Kabir Luebs (jkluebs)
Assigned to: Jason Tishler (jlt63)
Summary: remove -static option from cygwinccompiler

Initial Comment:
Currently, the cygwinccompiler.py compiler handling in
distutils is invoking the cygwin and mingw compilers
with the -static option. 

Logically, this means that the linker should choose to
link to static libraries instead of shared/dynamically
linked libraries.

Current win32 binutils expect import libraries to have
a .dll.a suffix and static libraries to have .a suffix.
If -static is passed, it will skip the .dll.a
libraries. This is pain if one has a tree with both
static and dynamic libraries using this naming
convention, and wish to use the dynamic libraries.

The -static option being passed in distutils is to get
around a bug in old versions of binutils where it would
get confused when it found the DLLs themselves.

The decision to use static or shared libraries is site
or package specific, and should be left to the setup
script or to command line options.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2003-04-10 08:19

Message:
Logged In: YES 
user_id=86216

After some more reflection, I would like to revert
the original patch and apply my version,
cygwinccompiler.py-shared.diff, instead.

My reasons are the following:

1. support for older toolchains is retained
2. support for new toolchains (i.e., ld -shared)
is added

The goal of my approach is to avoid breaking
older toolchains while adding better support for
newer ones.

John and/or anyone else, is my approach
acceptable? Can you find any problems with it?

Thanks.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-04-09 08:23

Message:
Logged In: YES 
user_id=86216

Checked in as Lib/distutils/cygwinccompiler.py 1.22.

Sorry, for sluggish response time.

I will create separate SF patches for the forthcoming,
related patches.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-04-01 10:11

Message:
Logged In: YES 
user_id=86216

Martin,

Thanks for your approval.

I would like to check in the changes in parts. For example:

1. John's remove -static patch.
2. my get_versions() fix patch
3. my -shared patch
4. etc.

In this way, I can more easily roll back if I goof. Can I just
attach more patches to this one? Or, should I create a new
SF patch for each of my patches?

----------------------------------------------------------------------

Comment By: Martin v. L÷wis (loewis)
Date: 2003-03-31 12:33

Message:
Logged In: YES 
user_id=21627

jlt63: Your proposed changes all sound fine.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-03-31 08:02

Message:
Logged In: YES 
user_id=86216

jkluebs> I can help with testing. I have access to W2K
jkluebs> and Win98 (ugh) boxen. I don't mind
jkluebs> installing a few older toolchains if you
jkluebs> think that's necessary.

Thanks for the offer. I'm set up for the
current Cygwin and Mingw tool chains. Let's
wait to see if testing with older ones is
necessary.

jkluebs> I think any C/C++ python extension using
jkluebs> plain distutils (no fancy hacks added on) and
jkluebs> has one or more DLL dependencies is a good
jkluebs> test case.

Can you point me to one that builds OOTB
under Python 2.2.2?

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-03-31 07:58

Message:
Logged In: YES 
user_id=86216

loewis> I'm in favour of applying this patch, and
loewis> also of patches that mandate recent Cygwin
loewis> releases;

I would like to apply an enhanced version of
this patch.  By enhanced, I mean using "gcc
-shared" (no more dllwrap and gcc -mdll) and
removing redundant gcc options, etc.

Additionally, I would like to fix
get_versions() so it can deal with versions
that only have two components (e.g., 3.2) as
opposed to requiring three (e.g. 2.95.3).

Are these changes acceptable?

loewis> if such patches are implemented, the minimum
loewis> required Cygwin version should be stated
loewis> somewhere.

I propose that the currently available Cygwin
and Mingw tool chains be that above stated
minimum. Is this acceptable? Unfortunately, I
have no idea where the above stated
"somewhere" shoud be.

----------------------------------------------------------------------

Comment By: John Kabir Luebs (jkluebs)
Date: 2003-03-28 14:31

Message:
Logged In: YES 
user_id=87160

I can help with testing. I have access to W2K and Win98
(ugh) boxen. I don't mind installing a few older toolchains
if you think that's necessary.

I think any C/C++ python extension using plain distutils (no
fancy hacks added on) and has one or more DLL dependencies
is a good test case.


----------------------------------------------------------------------

Comment By: Martin v. L÷wis (loewis)
Date: 2003-03-28 13:15

Message:
Logged In: YES 
user_id=21627

I'm in favour of applying this patch, and also of patches
that mandate recent Cygwin releases; if such patches are
implemented, the minimum required Cygwin version should be
stated somewhere.

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-03-28 12:16

Message:
Logged In: YES 
user_id=86216

John, would you be willing to help test or supply me with
test cases? I have built exactly one Win32 extension.

----------------------------------------------------------------------

Comment By: John Kabir Luebs (jkluebs)
Date: 2003-03-28 11:56

Message:
Logged In: YES 
user_id=87160

The -mdll --entry DllMain@12  option is guarded for an old
version of gcc that did not have the correct specs to accept
-shared.
I didn't touch it, even though it's crazy if anyone is using
such an old and buggy toolchain.

--shared and --dll are equivalent as far as ld is concerned. 

----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2003-03-28 09:41

Message:
Logged In: YES 
user_id=86216

Note that I only have minimal experience building
Win32 extensions modules...

This patch works "fine" with my *very* limited testing.
Specifically, I successfully rebuilt the Win32 readline
module with it applied.

BTW, this area of Distutils probably should be revisited
to bring it up to date. For example, the "-mdll --entry
_DllMain@12" options could be replaced by "-shared".

----------------------------------------------------------------------

Comment By: Martin v. L÷wis (loewis)
Date: 2003-03-27 15:03

Message:
Logged In: YES 
user_id=21627

Jason, can you take a look? If not, please unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=709178&group_id=5470