From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: Failure during build of Python 3.8 via cygport
Date: Tue, 15 Dec 2020 13:14:00 +0100 [thread overview]
Message-ID: <20201215121400.GC4560@calimero.vinschen.de> (raw)
In-Reply-To: <20201215120626.GB4560@calimero.vinschen.de>
On Dec 15 13:06, Corinna Vinschen via Cygwin-developers wrote:
> 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.
I created new developer snapshots.
Corinna
prev parent reply other threads:[~2020-12-15 12:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a7bcec5f-b01b-c1e4-81e6-1990f11e351e@maxrnd.com>
[not found] ` <Pine.BSF.4.63.2012112223120.53260@m0.truegem.net>
[not found] ` <758d2138-587b-2970-6c35-69d5c655a598@maxrnd.com>
2020-12-14 10:42 ` Mark Geisert
2020-12-14 11:33 ` Corinna Vinschen
2020-12-15 8:06 ` Mark Geisert
2020-12-15 8:52 ` Marco Atzeri
2020-12-15 9:07 ` Mark Geisert
2020-12-15 12:06 ` Corinna Vinschen
2020-12-15 12:14 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201215121400.GC4560@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).