Gettext build/use issue on Cygwin
Eric Blake
ebb9@byu.net
Wed Mar 15 13:20:00 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please keep replies ON THE LIST, so that you can get help from the group.
I adjusted the Reply-to accordingly: http://cygwin.com/acronyms/#PPIOSPE
Furthermore, on the cygwin lists, it is good netiquette to reply in
context instead of on top, and to avoid broadcasting raw email addresses
in the message body. Reformatted accordingly:
http://cygwin.com/acronyms/#TOFU, http://cygwin.com/acronyms/#PCYMTNQREAIYR
>
> -------- Original Message --------
> Subject: RE: Gettext build/use issue on Cygwin
> Date: Wed, 15 Mar 2006 06:57:04 -0500
> To: 'Eric Blake'
>
> -----Original Message-----
> From: Eric Blake [mailto:ebb9 AT byu DOT net]
> Which version of tar? Following the directions here:
> > Problem reports: http://cygwin.com/problems.html
>
> and including a text attachment of cygcheck -svr output would have been
> helpful. Also, I wonder if you are experiencing data corruption due to
> a
> text mount (again, cygcheck output would have made that obvious).
>
> At any rate, I don't know if the gettext archive really does have weird
> stuff in it, or if tar is mishandling a valid archive. I am currently
> working on putting together a tar 1.15.90 release, which has a number of
> bug
> fixes beyond the current 1.15.1, so maybe that will help your issue.
>
> Thank you for getting back to me.
> I reinstalled both gzip and tar, same problems showed.
> tar (GNU tar) 1.15.1
> gzip 1.3.5
>
> Apologies for not including the cygcheck -- I spent several hours trying
> to
> find any way to report the problem I've been seeing, actually hunting
> for a
> direct method to send a report to gettext people, ended up with a bunch
> of
> bad e-mail bug-reporting addresses.
The bug-gettext (aka bug-gnu-utils) mailing list at lists.gnu.org is
currently down - the GNU project had a massive database failure last month
that has severely impacted their mailing lists for several weeks. But if
you are only experiencing the problem on cygwin, then the right thing to
do is contact the cygwin lists first, so the package maintainers can
decide whether it really is an upstream problem or just a porting issue.
>
> Attached is a text file containing the cygcheck output.
>
And indeed, my guess that you might be running text mounts is confirmed:
. /cygdrive user
textmode,cy
gdrive
C:\cygwin / system textmode
C:\cygwin/bin /usr/bin system textmode
C:\cygwin/lib /usr/lib system textmode
C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode
. /cygdrive system
textmode,cy
gdrive
Use the 'mount' tool to remount things as binary, and see if that improves
the situation (development tools don't tend to work very well in text
environments).
>
> If I independently run
> gzip -d "archive.tar.gz"
> I see it decompress the archive to a .tar
> If I then run
> Tar xf archive.tar
> I see the archive directory with expected contents (ABOUT-NLS,v and the
> set
> of directories and files below it, including intl)
> But for whatever reason, the complete command line:
> gzip -d -c < "$gettext_dir/archive.tar.gz" | (cd "$cvs_dir" && tar xf -)
>
> Generates the errors originally reported.
So it would seem that somehow running things through the pipe, with text
mounts underneath, may be causing the textmode corruption. I'll see if I
can reproduce that locally (I don't normally use textmode, for a reason).
>
> To check once more, I commented out my change to autopoint, as well as
> commenting out the "rm" at the end of autopoint that erases the temp
> directories. The output of my bootstrap shows:
> + autopoint -f
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
>
> gzip: stdin: invalid compressed data--crc error
>
> gzip: stdin: invalid compressed data--length error
> tar: Error exit delayed from previous errors
> Copying file ABOUT-NLS
> + aclocal-1.9 -I m4 -I extras/contrib/share/aclocal
> + autoconf
>
Your changes are a hack to work around the symptoms, not solve the
original problem. While it works for you, I doubt that it will be applied
either upstream or to the official cygwin gettext distribution.
> If the intl directory was being created, after the "Copying file
> ABOUT-NLS"
> line I would expect to see output lines related to creating and
> populating
> the intl structure in my project.
>
> And when I check my project root directory, I see that a temporary
> $cvs_dir
> has been created. This directory contains a CVSROOT subdirectory, and
> an
> archive subdirectory. The archive subdirectory only contains
> ABOUT-NLS,v --
> no intl subdirectory (or anything else).
>
> If I revert to the Cygwin gettext 14.1 package, I still see the
> complaints
> about gzip and tar, but for some reason that intl directory, and files,
> do
> get created in my project trunk. Since it was working with 14.1 I
> ignored
> the errors, but now can't -- it's not "recovering", pulling those intl
> files
> out of its hat.
>
> Thanks again -- I have figured out the ugly kludge that works for me,
> but
> expect that at least some others have the same issue.
- --
Life is short - so eat dessert first!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEGBSk84KuGfSFAYARAoNgAKDClolRZjGdTP/Gv95OsVohmksySACfVL/T
GwzfxWyBrXKObQ928cGZAYs=
=UpDl
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.txt
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060315/5c59be8e/attachment.txt>
-------------- next part --------------
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
More information about the Cygwin
mailing list