You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/tarekziade'closed_at=<Date2021-02-03.18:19:07.597>created_at=<Date2008-03-21.16:41:36.688>labels= ['build', 'library']
title='Use The CygwinCCompiler Under Cygwin'updated_at=<Date2021-02-03.18:19:07.597>user='https://bugs.python.org/dstanek'
I was having an issue building extension with a fresh checkout of
revision 61699. distutils was using the UnixCCompiler. This is not able
to find thec correct libraries to link against. I made a few changes in
this patch:
distutils now uses the CygwinCCompiler when building extensions on the
Cygwin platform
CygwinCCompiler.static_lib_extension needed to be .lib.a instead of
just .a
Added some files to the svn:ignore property on a handful of directories.
The patch contains lots of unrelated changes. Can you please provide a
clean patch and some doc updates? The rest looks fine to me.
dstanek commented on Mar 21, 2008
dstanekmannequin
MannequinAuthor
More actions
As Christian suggested I removed the unrelated svn:ignore changes.
jayvee commented on May 19, 2008
jayveemannequin
Mannequin
More actions
The following will also let environment variables be passed to the
CygwinCCompiler.
--- orig/sysconfig.py 2008-05-19 00:26:03.953125000 -0700+++ copy/sysconfig.py 2008-05-19 00:14:51.609375000 -0700@@ -145,7 +145,7 @@
Mainly needed on Unix, so we can plug in the information that
varies across Unices and is stored in Python's Makefile.
"""
- if compiler.compiler_type == "unix":+ if compiler.compiler_type in ("unix", "cygwin"):
(cc, cxx, opt, cflags, ccshared, ldshared, so_ext) = \
get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
'CCSHARED', 'LDSHARED', 'SO')
ocean-city commented on Sep 23, 2008
ocean-citymannequin
Mannequin
More actions
# I found this infomation via "svn blame"
According to bpo-403947, cygwin once used CygwinCCompiler, and problem
was there, swiched to UnixCCompier. (r19674)
If this issue is not solved yet, maybe it's not good to go back to
CygwinCCompiler. (maybe)
rpetrov commented on Sep 24, 2008
rpetrovmannequin
Mannequin
More actions
May be check for compiler.compiler_type (from sysconfig.py ) has to be
replaced with a check for descendant classes of UnixCCompiler, i.e. to
include mingw32 too ?
Also CygwinCCompiler __init__ has to be reviewed too. As example :
-------------
# Hard-code GCC because that's what this is all about.
# XXX optimization, warnings etc. should be customizable.
self.set_executables(compiler='gcc -mcygwin -O -Wall',
.....
-------------
May override in unexpected way settings from customize_compiler.
I thin that proposed modification in sysconfig.py with removing(or
replacing) of self.set_executables from CygwinCCompiler __init__ will
help me for bpo-3871 (cross building python for mingw32 with distutils).
As example I will remove a hack in the setup.py:
-----------------------
@@ -196,8 +196,26 @@
if compiler is not None:
(ccshared,cflags) =
sysconfig.get_config_vars('CCSHARED','CFLAGS')
args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
++ # FIXME: Is next correct ?+ # To link modules we need LDSHARED passed to setup.py otherwise+ # distutils will use linker from build system if cross-compiling.+ linker_so = os.environ.get('LDSHARED')+ if linker_so is not None:+ args['linker_so'] = linker_so+
self.compiler.set_executables(**args)
Thanks to Hirokazu who point me, in an another thread, that cygwin build
don't use CygwinCCompiler.
rpetrov commented on Sep 24, 2008
rpetrovmannequin
Mannequin
More actions
P.S. : about: static_lib_extension = ".dll.a" - it is suffix for import
library and "unixccompiler.py.diff" patch from bpo-1706863 propose
dylib_lib_extension = ".dll.a" .
rpetrov commented on Sep 24, 2008
rpetrovmannequin
Mannequin
More actions
I forgot an another issue in CygwinCCompiler __init__:
if gcc isn't version "2.91.57" then method will set dll_libraries to
result of get_msvcr(), but the result may be is None. In this case link
method fail on the line libraries.extend(self.dll_libraries).
jlt63 commented on Sep 24, 2008
jlt63mannequin
Mannequin
More actions
I don't think the patch, cygwin-smaller.diff, is correct. The value of
static_lib_extension needs to remain ".a". Otherwise, shared
extensions attempting to build against a library that only offers a
static version will fail to link.
AFAICT, Cygwin needs a concept that is not currently supported by
distutils -- the ability to specify a shared library *link* extension
(i.e., ".dll.a") which is different from the shared library extension
(i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin
they are different because of how Windows handles DLLs -- import
library versus DLL.
Shouldn't the import library name end with .lib? I've run up against this building PyLucene with MinGW. There seems to be code to figure this out already in CygwinCCompiler, but it's commented out (and arguably incomplete).
rpetrov commented on Aug 4, 2013
rpetrovmannequin
Mannequin
More actions
Hi,
Now bpo-18654 "modernize mingw&cygwin compiler classes" contain enhancement that could be reused by this issue: patch "0007-MINGW-compiler-cygwin-provides-its-own-C-runtime.patch
" from archive , i.e. lets avoid change in get_msvcr() that return. Mingw is also impacted but is addresses in another patches. As separate patch is 'compiler customization' - more advanced version then proposed by Jeevan Varshney (jayvee)
A separate bpo-18634 "find import library" address .dll.a suffix based on existing distutil functionality.
Also bpo-18633 "Mingw32CCompiler as default compiler for mingw* build" adds same fixes from unix compiler class into Cygwin one - ref '# Chop off the drive'
So with above I think that cygwin compiler could be switched back from unix to own.
CygwinCCompiler seems legacy code.
In v3.4 latest rivision, Distutils has made to work that is a patching to UnixCCompiler.
So, I have a think that doesn't need to use CygwinCCompiler to build on Cygwin.
I have upload a patch for UnixCCompiler. The patch has modified from http://cygwin.org package.
I have confirmed Masayuki's patch (3.4-distutils-shlibext.patch) fixes a few build issues on Cygwin.
At its core, what it's fixing is allowing UnixCCompiler.find_library_file to find import libraries on Cygwin.
That in turn is necessary for --with-system-ffi to work, which is currently needed; on Cygwin64 at least the ffi compile as part of _ctypes fails (a separate issue to be addressed separately). But in the meantime making --with-system-ffi work again goes a long way.
It should be noted there is a patch at bpo-18654 to make the CygwinCCompiler class work again, and switch to using it to handle Cygwin-specific build issues as origially intended. I intend to review that ticket and spend some time on it, but it's more complex and not necessarily the simplest way forward.
In the meantime this one-line patch accomplishes a fair bit.
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools
Activity
dstanek commentedon Mar 21, 2008
I was having an issue building extension with a fresh checkout of
revision 61699. distutils was using the UnixCCompiler. This is not able
to find thec correct libraries to link against. I made a few changes in
this patch:
Cygwin platform
just .a
tiran commentedon Mar 21, 2008
The patch contains lots of unrelated changes. Can you please provide a
clean patch and some doc updates? The rest looks fine to me.
dstanek commentedon Mar 21, 2008
As Christian suggested I removed the unrelated svn:ignore changes.
jayvee commentedon May 19, 2008
The following will also let environment variables be passed to the
CygwinCCompiler.
ocean-city commentedon Sep 23, 2008
# I found this infomation via "svn blame"
According to bpo-403947, cygwin once used CygwinCCompiler, and problem
was there, swiched to UnixCCompier. (r19674)
If this issue is not solved yet, maybe it's not good to go back to
CygwinCCompiler. (maybe)
rpetrov commentedon Sep 24, 2008
May be check for compiler.compiler_type (from sysconfig.py ) has to be
replaced with a check for descendant classes of UnixCCompiler, i.e. to
include mingw32 too ?
Also CygwinCCompiler __init__ has to be reviewed too. As example :
-------------
# Hard-code GCC because that's what this is all about.
# XXX optimization, warnings etc. should be customizable.
self.set_executables(compiler='gcc -mcygwin -O -Wall',
.....
-------------
May override in unexpected way settings from customize_compiler.
I thin that proposed modification in sysconfig.py with removing(or
replacing) of self.set_executables from CygwinCCompiler __init__ will
help me for bpo-3871 (cross building python for mingw32 with distutils).
As example I will remove a hack in the setup.py:
-----------------------
Thanks to Hirokazu who point me, in an another thread, that cygwin build
don't use CygwinCCompiler.
rpetrov commentedon Sep 24, 2008
P.S. : about: static_lib_extension = ".dll.a" - it is suffix for import
library and "unixccompiler.py.diff" patch from bpo-1706863 propose
dylib_lib_extension = ".dll.a" .
rpetrov commentedon Sep 24, 2008
I forgot an another issue in CygwinCCompiler __init__:
if gcc isn't version "2.91.57" then method will set dll_libraries to
result of get_msvcr(), but the result may be is None. In this case link
method fail on the line libraries.extend(self.dll_libraries).
jlt63 commentedon Sep 24, 2008
I don't think the patch, cygwin-smaller.diff, is correct. The value of
static_lib_extension needs to remain ".a". Otherwise, shared
extensions attempting to build against a library that only offers a
static version will fail to link.
AFAICT, Cygwin needs a concept that is not currently supported by
distutils -- the ability to specify a shared library *link* extension
(i.e., ".dll.a") which is different from the shared library extension
(i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin
they are different because of how Windows handles DLLs -- import
library versus DLL.
janssen commentedon Mar 19, 2010
Shouldn't the import library name end with .lib? I've run up against this building PyLucene with MinGW. There seems to be code to figure this out already in CygwinCCompiler, but it's commented out (and arguably incomplete).
rpetrov commentedon Aug 4, 2013
Hi,
Now bpo-18654 "modernize mingw&cygwin compiler classes" contain enhancement that could be reused by this issue: patch "0007-MINGW-compiler-cygwin-provides-its-own-C-runtime.patch
" from archive , i.e. lets avoid change in get_msvcr() that return. Mingw is also impacted but is addresses in another patches. As separate patch is 'compiler customization' - more advanced version then proposed by Jeevan Varshney (jayvee)
A separate bpo-18634 "find import library" address .dll.a suffix based on existing distutil functionality.
Also bpo-18633 "Mingw32CCompiler as default compiler for mingw* build" adds same fixes from unix compiler class into Cygwin one - ref '# Chop off the drive'
So with above I think that cygwin compiler could be switched back from unix to own.
BreamoreBoy commentedon Jul 9, 2014
From msg194383 issues bpo-18633, bpo-18634 and bpo-18654 are linked to this so is anybody up for providing a patch so that we can take this forward. See also bpo-4032.
ma8ma commentedon Apr 20, 2015
CygwinCCompiler seems legacy code.
In v3.4 latest rivision, Distutils has made to work that is a patching to UnixCCompiler.
So, I have a think that doesn't need to use CygwinCCompiler to build on Cygwin.
I have upload a patch for UnixCCompiler. The patch has modified from http://cygwin.org package.
Other big issues and patches for build on Cygwin:
bpo-21085, bpo-13756 -- compile error
bpo-14598, bpo-21124 -- C extension module
embray commentedon Aug 30, 2016
I have confirmed Masayuki's patch (3.4-distutils-shlibext.patch) fixes a few build issues on Cygwin.
At its core, what it's fixing is allowing UnixCCompiler.find_library_file to find import libraries on Cygwin.
That in turn is necessary for --with-system-ffi to work, which is currently needed; on Cygwin64 at least the ffi compile as part of _ctypes fails (a separate issue to be addressed separately). But in the meantime making --with-system-ffi work again goes a long way.
It should be noted there is a patch at bpo-18654 to make the CygwinCCompiler class work again, and switch to using it to handle Cygwin-specific build issues as origially intended. I intend to review that ticket and spend some time on it, but it's more complex and not necessarily the simplest way forward.
In the meantime this one-line patch accomplishes a fair bit.
zooba commentedon Feb 3, 2021
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools