From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8866 invoked by alias); 13 Jul 2012 22:04:11 -0000 Received: (qmail 8849 invoked by uid 22791); 13 Jul 2012 22:04:10 -0000 X-SWARE-Spam-Status: No, hits=-10.3 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_YG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Jul 2012 22:03:52 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6DM3puC023471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Jul 2012 18:03:51 -0400 Received: from [10.3.113.64] (ovpn-113-64.phx2.redhat.com [10.3.113.64]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q6DM3pOg018372 for ; Fri, 13 Jul 2012 18:03:51 -0400 Message-ID: <50009B44.4060504@redhat.com> Date: Fri, 13 Jul 2012 22:04:00 -0000 From: Eric Blake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: compiling coreutils with cygport References: In-Reply-To: OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4D34372273D0F7AB5E86D983" X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-07/txt/msg00293.txt.bz2 --------------enig4D34372273D0F7AB5E86D983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 4366 On 07/13/2012 03:25 PM, Jeff Janes wrote: > If I use setup.exe to download the src for coreutils (just by checking > the "Src?" checkbox in the gui) , and then use cygport to build it, it > fails. The reason it fails seems to be that ginstall.exe does not > have the proper manifest file so windows refuses to execute it. This > is the same error you get if you try to build coreutils downloaded > from upstream gnu sources. > GEN install.1 > help2man: can't get `--help' info from install.td/install Wow. I'm glad I build the coreutils package on my Windows XP box, where I'm not impacted by newer Window's stupidity. >=20 > If I delete the two patch files which setup.exe automatically > downloads into /usr/src (coreutils-8.15-1.src.patch and > coreutils-8.15-1.cygwin.patch), and then run cygport as before, it > compiles fine. But then it doesn't have any cygwin-specific patches, so you aren't getting the full coreutils experience that I have intended to package. (Hmm, that reminds me, I'm due for a coreutils upgrade for cygwin soon) > Also, it works if I delete all the files which > setup.exe downloads to /usr/src except for the > "coreutils-8.15-1.cygport" one, and then run: >=20 > cygport coreutils-8.15-1.cygport download prep compile >=20 > So it looks like the setup.exe is giving me a coreutils tar ball which > has already been patched to work with cygwin, but is also giving me > some patch files which undo that and cause it to be broken again. I > can work around that by deleting the patch files, but it doesn't seem > like that should be necessary. Is the problem in cygport, or > setup.exe, or in my understanding of how these things are supposed to > work together? setup.exe gives you the working tarball (which I compiled on a windows box that doesn't need a manifest file to be built), as well as the patches that are included in that tarball. If you don't apply the patches, then you aren't building the cygwin version of coreutils, at which point, if things work, great, but it's not quite relevant here. So the real trick is to figure out how to make the upstream make process work with the need for manifest files during the build (rather than my current solution of only creating manifest files after the build), and unfortunately, since I don't have access to anything newer than XP, I can't really test that. I'll be relying on you (or anyone else really bothered by this) to provide patches. > As an aside, the reason I wanted to build coreutils from source is > that I was trying to figure out why cut.exe is so slow, even under > LANG=3DC. It is slow both compared to a functionally equivalent > invocation of cygwin's awk.exe, and compared to running cut on a linux > VM. What I found was that cut.exe is slow because the "putchar" > function is slow under cygwin. cut.exe uses "putchar" to generate > its output, while awk.exe does not.=20 Actually, coreutils tries to use all the *_unlocked variants of stdio, since those have better speed in single-threaded programs (all but sort are single-threaded, and sort skips stdio). I do know that cygwin has putchar_unlocked, but does not have quite as many *_unlocked variants as Linux, so it may be a case where the configure logic to detect _unlocked functions went wrong and cygwin ends up using putchar instead of putchar_unlocked as a result. I'll have to look into it more. It may also be an efficiency thing - calling one putchar per byte is slower than calling operations to put a line at a time, just due to the sheer overhead of a function call. But looking at cut.c, it really is calling fwrite() for the bulk of a line, and saving putchar() for just the line terminator, which means the bulk of the processing isn't suffering from the putchar() slowdowns. > I'm kind of at a dead-end there, > as I can't figure out where putchar itself is implemented. In newlib (cygwin's libc). http://sourceware.org/newlib/ http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdio/putchar_u.c?= annotate=3D1.3&cvsroot=3Dsrc > So I've > just learned to use awk.exe rather than cut.exe when I care about > performance. Interesting observation, and may be one worth making upstream that cut.c isn't being as efficient as possible. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig4D34372273D0F7AB5E86D983 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 620 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQAJtGAAoJEKeha0olJ0Nq6osH/0hoPcJ9s8qQUrrUOrQ5hiJR eo+Y4CRGkxImiGeAT+xRMwIuYbKTUyGApnEFueCDzH3qRM760dzom+h2yhOz7VGj ZxaWxqdItpkQCA399ghZQLY9muuZF0OvHfUExkxTLs/2wmGrh0kPHQtH9BKK0809 KwaYh2jcSXmExrrSHal5K6a9cbB6bq2cH4RxyQIN+TXlBUfvlZCJsNN+l32la4S6 MpQelEwQ7BX5gEqimhA7SIU3jqUL2cCxoYBEcSWlmQYyRINEmwCr1LrNsJMYqUSO Q2VB8DwqCbEEpPl33nGfhdobW72ovEt64YLdAWwgAlL7FLZlXrKCBg1BFZxmSm0= =AnY/ -----END PGP SIGNATURE----- --------------enig4D34372273D0F7AB5E86D983--