[ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[cygwin]

gettext is the GNU package which provides 'national language support'
for other programs. It includes a number of utility programs.

This is a packaging and bugfix update of the gettext package(s).  This
will most likely be the final gettext update for the cygwin-1.5
distribution; future development will continue with gettext-0.17-10 for
cygwin-1.7.

    gettext-0.17-3
    gettext-devel-0.17-3
    libintl8-0.17-3
    libgettextpo0-0.17-3
    libasprintf0-0.17-3

CHANGES (gettext-0.17-1 ---> gettext-0.17-10):
(includes changes in the released but un-announced gettext-0.17-2)

* Fixed packaging bug in setup.hint for libasprintf0
* Fixed a bug in lib-link.m4 exposed when dependent libraries
  are installed in different directories. Also fixed upstream
  (in future gettext-0.18).
* Fixed an issue in the rpath (e.g. lib-link.m4) test suite
  where only the installed .m4 files were tested, rather than
  the in-package ones. This explains (and corrects) the
  odd rpath test results in gettext-0.17-1. See
  http://cygwin.com/ml/cygwin-announce/2008-11/msg00015.html
* Modified the rpath (e.g. lib-link.m4) test suite so that the
  tests continue to pass. As it happens, in gettext-0.15.1-X
  and previous, these tests never should have passed; they
  were erroneously linking statically. Now they link shared,
  and can't "find" their dependent DLLs without $PATH
  manipulation.  This is the correct behavior; but as we
  "expect" the test suite to pass, the test suite now also
  manipulates $PATH.
* Some modifications to gettext-runtime test_lock program to
  enable conditional execution of some subtests, and conditional
  debug/trace output (see below). This test appears twice --
  once in gettext-runtime and again in gettext-tools/gnulib-tests.
  Only the former was modified.

TESTSUITE RESULTS:

gettext-tools
===================================================================
All 300 tests passed (27 tests were not run)

gettext-tools/gnulib-tests
===================================================================
1 of 47 tests failed
(2 tests were not run)

the test_once subtest of test_link.exe fails. It is a duplicate of the
gettext-runtime test of the same name (see below). Sometimes, the test
must be killed manually, or it sometimes coredumps.

This is a new regression, but appears to be related to cygwin
thread/signal code, and not gettext, because it passed in gettext-0.17-1.


gettext-runtime
===================================================================
The test_lock, test_rwlock, and test_recursive_lock subtests all pass,
but the test_once subtest fails: sometimes it coredumps, and sometimes
it hangs and must be killed manually). Under cygwin-1.5, the test_once
subtest always segfaults unless compiled with -O0,  in which case it may
hang and must be killed manually.

However, when recompiled with debugging output, it succeeds (unless the
debugging output is sent to /dev/null, in which case it also hangs) --
this behavior is consistent on both cygwin-1.5 and -1.7.  This points to
a race condition of some kind, which (may, if conditions are right) lead
to stack overflow problem in the thread and/or signal handling code of
cygwin, or threads "missing" their signal and then waiting forever for
the signal that already arrived.


gettext-rpath
===================================================================
All 30 tests passed

The lib-link test suite has been modified for cygwin, in two ways:
(1) the test scripts extend the PATH to include the installation
    directories of the sub-dependent libraries, and
(2) the Makefiles for the executable tests extend the PATH to
    include the installation directory of the direct dependent
    library.
In this way, the PATH is sure to include all directories which contain
the DLLs used by the test application. However, all of these changes are
simply workarounds for the primary defect on windows: there IS no RPATH
support. Modifying the $PATH is no different than modifying
$LD_LIBRARY_PATH on other platforms -- and all of these rpath tests are
*supposed* to be checking that RPATH support actually works *without*
manipulating $LD_LIBRARY_PATH.

No matter how you slice it on windows, it doesn't. So ALL of these
changes are "cheating". Earlier versions of gettext (0.15 and before)
*erroneously* passed many of these tests *without* the workaround above
-- because the tests in which the dependent and sub-dependent libraries
were installed into different prefixes did NOT actually link against
those DLLs, but linked statically. So, naturally, there was no runtime
"can't find the DLL" issue. This was "fixed" in gettext-0.17 -- so now
these tests began to fail, as they always should have done, without the
workarounds described above.

--
Charles Wilson
gettext volunteer maintainer for cygwin

====================================================================

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Yaakov (Cygwin/X)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck Wilson wrote:
> This is a packaging and bugfix update of the gettext package(s).  This
> will most likely be the final gettext update for the cygwin-1.5
> distribution; future development will continue with gettext-0.17-10 for
> cygwin-1.7.

Chuck,

I've been testing this patch[1] for some time within Ports, and it has
solved a lot of the problems I was having with libtool-2.2.  Could you
please consider this for inclusion in your gettext package?

[1] http://cygwin.com/ml/cygwin/2008-10/msg00346.html


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkmHxtEACgkQpiWmPGlmQSP7vACgqoKcKjqD4ar/OxvD331h2uz/
rcEAn1HiBBTkYQBYb/Akx0oi55ntEwU6
=ez2E
-----END PGP SIGNATURE-----

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Yaakov (Cygwin/X)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yaakov (Cygwin/X) wrote:
> Chuck,
> 
> I've been testing this patch[1] for some time within Ports, and it has
> solved a lot of the problems I was having with libtool-2.2.  Could you
> please consider this for inclusion in your gettext package?
> 
> [1] http://cygwin.com/ml/cygwin/2008-10/msg00346.html

Ping?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEAREIAAYFAknRn80ACgkQpiWmPGlmQSN5aQCY9TrTS1V0fWyWswbcyQ+mbpAh
2ACfVoFmScWMIKIhBNCwcPdgCKPELsw=
=/oAT
-----END PGP SIGNATURE-----

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Charles Wilson]

Yaakov (Cygwin/X) wrote:
>> I've been testing this patch[1] for some time within Ports, and it has
>> solved a lot of the problems I was having with libtool-2.2.  Could you
>> please consider this for inclusion in your gettext package?
> 
>> [1] http://cygwin.com/ml/cygwin/2008-10/msg00346.html

Well, I'm not too thrilled about automatically upgrading every package
that uses gettext to the latest version -- even those that aren't being
built *for cygwin* itself.  Basically, with your patch, if you do an
autoreconf on the cygwin platform, then you're going to bump to
gettext-0.17 no matter what you've listed in your configure.ac.

That's fine -- probably -- for cygport'ed packages being built *for*
cygwin.  Not so fine for packages that are merely being developed ON
cygwin as the development host (I've been told that there are folks who
do that).

However, there is a /real/ bug in older gettexts that you've encountered
and are trying to work around.  And, it's best if that workaround were
somewhat automated (e.g. otherwise you'd just say "edit configure.ac and
change the value of AM_GNU_GETTEXT_VERSION").

What we need is an "out of band" method of communicating to autopoint --
even when it is invoked indirectly by autoreconf -- that you do, or do
not, want to respect the value of AM_GNU_GETTEXT_VERSION in configure.ac.

Seems to me the right way to do that is an environment variable. If
autopoint was sensitive to, say:

AUTOPOINT_FORCE_GETTEXT_VERSION

then you could ensure that cygport (always?) sets that variable to
(e.g.) 0.17 (or maybe a magic value "CURRENT_INSTALLED" or something).

Does that seem like a reasonable approach to you?

--
Chuck

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Yaakov (Cygwin/X)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> Well, I'm not too thrilled about automatically upgrading every package
> that uses gettext to the latest version -- even those that aren't being
> built *for cygwin* itself.  Basically, with your patch, if you do an
> autoreconf on the cygwin platform, then you're going to bump to
> gettext-0.17 no matter what you've listed in your configure.ac.

Yes, it essentially changes the meaning of the AC_GNU_GETTEXT_VERSION
argument from == to >=.

> That's fine -- probably -- for cygport'ed packages being built *for*
> cygwin.  Not so fine for packages that are merely being developed ON
> cygwin as the development host (I've been told that there are folks who
> do that).

Hmmm, hadn't thought about that, although I don't understand why an
actively developed package shouldn't be using gettext-0.17 already.

> However, there is a /real/ bug in older gettexts that you've encountered
> and are trying to work around.  And, it's best if that workaround were
> somewhat automated (e.g. otherwise you'd just say "edit configure.ac and
> change the value of AM_GNU_GETTEXT_VERSION").

Exactly.

> What we need is an "out of band" method of communicating to autopoint --
> even when it is invoked indirectly by autoreconf -- that you do, or do
> not, want to respect the value of AM_GNU_GETTEXT_VERSION in configure.ac.
> 
> Seems to me the right way to do that is an environment variable. If
> autopoint was sensitive to, say:
> 
> AUTOPOINT_FORCE_GETTEXT_VERSION
> 
> then you could ensure that cygport (always?) sets that variable to
> (e.g.) 0.17 (or maybe a magic value "CURRENT_INSTALLED" or something).
> 
> Does that seem like a reasonable approach to you?

What about enabling the autopoint -V option (which is currently
commented out as "dangerous" on lines 164-166,212-222), and changing the
version mismatch error on line 276 into a message or warning?  Cygport
could then export AUTOPOINT="autopoint -V 0.17" when libtool usage is
detected.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAknUKO0ACgkQpiWmPGlmQSN4ZQCeNOC6nxiJrZHcUSdhYacfOWFR
4G4AnjBxD0HpN7RZy9xIvw0LzSwlV8su
=Ng29
-----END PGP SIGNATURE-----

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Charles Wilson]

Yaakov (Cygwin/X) wrote:
> What about enabling the autopoint -V option (which is currently
> commented out as "dangerous" on lines 164-166,212-222), and changing the
> version mismatch error on line 276 into a message or warning?  Cygport
> could then export AUTOPOINT="autopoint -V 0.17" when libtool usage is
> detected.

I like it. You're basically using the AUTOPOINT variable itself as the
"out of band" communication mechanism.  I've got a build running now;
but it will be a while before the test suite finishes up and I've dotted
all the i's for a new release.

--
Chuck

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

Re: [ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[Yaakov (Cygwin/X)]

On 02/04/2009 19:29, Charles Wilson wrote:
> I like it. You're basically using the AUTOPOINT variable itself as the
> "out of band" communication mechanism.  I've got a build running now;
> but it will be a while before the test suite finishes up and I've dotted
> all the i's for a new release.

Looks good to me; cygport 0.9.6 will depend on it.


Yaakov

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