From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-042.btinternet.com (mailomta26-re.btinternet.com [213.120.69.119]) by sourceware.org (Postfix) with ESMTPS id 5C7513857C4E for ; Sun, 11 Oct 2020 17:14:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5C7513857C4E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-042.btinternet.com with ESMTP id <20201011171431.MWES13627.re-prd-fep-042.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net> for ; Sun, 11 Oct 2020 18:14:31 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [86.179.113.52] X-OWM-Source-IP: 86.179.113.52 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrheehgdduudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepleeigeehgefhveefvefhvdeiudfgvdeuhfejheetjefffefhueduteehuefgfffhnecukfhppeekiedrudejledruddufedrhedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdduuddungdpihhnvghtpeekiedrudejledruddufedrhedvpdhmrghilhhfrhhomhepoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnqdguvghvvghlohhpvghrshestgihghifihhnrdgtohhmqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (86.179.113.52) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9BDD0155D11EA for cygwin-developers@cygwin.com; Sun, 11 Oct 2020 18:14:31 +0100 Subject: Re: Build spends a long time in "mkimport". To: cygwin-developers@cygwin.com References: From: Jon Turney Message-ID: <19ee7db1-5f95-8ecc-4cdc-9c542cdb9e53@dronecode.org.uk> Date: Sun, 11 Oct 2020 18:14:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 17:14:34 -0000 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.