From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin-developers@cygwin.com
Subject: Re: Build spends a long time in "mkimport".
Date: Sun, 11 Oct 2020 18:14:29 +0100 [thread overview]
Message-ID: <19ee7db1-5f95-8ecc-4cdc-9c542cdb9e53@dronecode.org.uk> (raw)
In-Reply-To: <fd7836b6-f428-6c18-3656-5123a47197f5@maxrnd.com>
On 11/10/2020 08:24, Mark Geisert wrote:
> Kaz Kylheku (Cygwin) via Cygwin wrote:
>> Hi All,
>>
>> When building the Cygwin DLL, this single step takes almost ten minutes:
>>
>> ../../.././winsup/cygwin/mkimport --cpu=i686 --ar=ar --as=as
>> --nm=nm --objcopy=objcopy \
>> --replace=atexit= --replace=timezone= --replace=uname=uname_x
>> --replace=__xdrrec_getrec=
>>
>> [ .. SNIP ... ]
>>
>> --replace=truncate=_truncate64 libcygwin.a cygdll.a
>> _cygwin_crt0_common.o \
>> atexit.o cygwin_attach_dll.o cygwin_crt0.o dll_entry.o dll_main.o
>> dso_handle.o \
>> libcmain.o premain0.o premain1.o premain2.o premain3.o
>> pseudo-reloc-dummy.o
>>
>> What's puzzling is that there is very CPU activity during this time.
>> It's launching
>> some objcopy commands.
>>
>> Is there some documentation that provides an overview of what exactly
>> this does,
>> other than studying its perl source code?
I'm afraid not.
>> Maybe it can be sped up?
Almost certainly and yes please :)
>> I'm going to have to cycle quite a few times on some changes, so this
>> is frustrating.
>
> Hi Kaz,
> I'm redirecting this to the cygwin-developers list as it's a Cygwin
> build issue. Please follow up there.
>
> I've looked at .../winsup/cygwin/mkimport for the same reason as you --
> it takes forever on my Windows machines. But I don't know enough perl
> to make any changes.
>
> Near the end of mkimport there's a loop over all the "--replace" args,
> essentially. For each one there are two system() calls launching two
I think this perhaps is looping over all the exported symbols.
> objcopy processes to do something. This is much slower on Cygwin than
> it would be cross-building from Linux, for example.
What I think mkimport is doing: This produces the import library for
the Cygwin DLL, which is actually a 'hybrid' library. Mainly it
consists of import stubs for functions in the DLL (some of which are
renamed by --replace options), but it also contains some specific object
files directly (this is stuff called by crt0.o, but idk why it's can't
be in the DLL).
If it's actually the objcopy which is slow, then it would be nice to
understand why, although they could also be parallelized.
next prev parent reply other threads:[~2020-10-11 17:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <af9f360a0a782f3c4db698e9f4584d16@mail.kylheku.com>
2020-10-11 7:24 ` Mark Geisert
2020-10-11 16:52 ` Ken Brown
2020-10-11 17:14 ` Jon Turney [this message]
2020-10-13 10:30 ` Corinna Vinschen
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=19ee7db1-5f95-8ecc-4cdc-9c542cdb9e53@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--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).