Re: Failure during build of Python 3.8 via cygport

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Dec 15 00:06, Mark Geisert wrote:
> Hi Corinna,
> 
> Corinna Vinschen via Cygwin-developers wrote:
> > On Dec 14 02:42, Mark Geisert wrote:
> [...]
> > > Debugging Python's os.uname showed Cygwin's uname() being called with a
> > > 'struct uname' as defined in /usr/include/sys/utsname.h, which is fine.  But
> > > it's the "old" pre-335 uname() interface being called, not the "new" 335+
> > > interface uname_x().  Note that the famous 'mkimport' script, used when
> > > building the Cygwin DLL, has an arg "--replace=uname=uname_x" which I
> > > believe is supposed to equate the two names so the code in uname_x() is
> > > called whether the interface is uname_x() or uname().  That's not happening.
> [...]
> > > 'nm' shows that both uname and uname_x exist in libcygwin.a and also
> > > cygdll.a. And a newly-created Cygwin DLL has both functions, with different
> > > addresses.
> > > That's wrong, isn't it?
> > 
> > No, it isn't.  The old uname entry point is still required for old
> > applications built prior to API version 335.  If you build a new
> > application it will actually call uname_x when it tries to call uname
> > since that's how the libcygwin.a layer translates it.
> > 
> > It's a bit unfortunate that uname_x is exported by libcygwin.a
> > as well (in theory it should only export uname, pointing to uname_x
> > in the DLL), but this is how it always was, as you can see in
> > the 32 bit build with symbols only available there, e. g. aclcheck:
> > 
> >    $ nm libcygwin.a | grep aclcheck
> >    00000000 I __imp___aclcheck
> >    00000000 I __imp___aclcheck32
> >    00000000 I __imp__aclcheck
> >    00000000 T __aclcheck
> > 	   U __imp___aclcheck
> >    00000000 T __aclcheck32
> > 	   U __imp___aclcheck32
> >    00000000 T _aclcheck
> > 	   U __imp___aclcheck32
> > 
> > In retrospect, uname_x should be named _uname_x or so, with a leading
> > underscore, so as not to pollute the namespace, but either way, that
> > isn;t your problem.
> 
> OK, I see.
> 
> > The problem here might be that you get the old uname function if
> > you dlopen the cygwin dll and dlsym(hdl, "uname").  Is that the
> > case in python?
> 
> Yes it is.
> 
> > If so, I have a simple, dirty workaround below.  Can you check if that's
> > the problem, please?
> 
> A new Cygwin DLL built with your patch does correct this 'uname' issue when
> building Python.  Wonderful!
> Thank you very much!

Great, thanks for testing and confirming!  I pushed the patch.


Corinna