X-Recipient:	archive-cygwin AT delorie DOT com
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
Message-ID:	<50009B44.4060504@redhat.com>
Date:	Fri, 13 Jul 2012 16:03:48 -0600
From:	Eric Blake <eblake AT redhat DOT com>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: compiling coreutils with cygport
References:	<CAMkU=1yRPm7vu30taP6Y0xNy3BRZxVOYUAL_aMCo794SSbGb6Q AT mail DOT gmail DOT com>
In-Reply-To:	<CAMkU=1yRPm7vu30taP6Y0xNy3BRZxVOYUAL_aMCo794SSbGb6Q@mail.gmail.com>
OpenPGP:	url=http://people.redhat.com/eblake/eblake.gpg
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

--------------enig4D34372273D0F7AB5E86D983
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 AT redhat DOT 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"

-----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--

- Raw text -