Failure during build of Python 3.8 via cygport
Mark Geisert
mark@maxrnd.com
Tue Dec 15 08:06:09 GMT 2020
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!
..mark
More information about the Cygwin-developers
mailing list