Message-Id: <announce.495E4615.1080100@cwilson.fastmail.fm>
Date: Fri, 02 Jan 2009 11:51:33 -0500
From: cygwin AT cwilson DOT fastmail DOT fm
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: [ANNOUNCEMENT] [1.7] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-10
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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

This is the first release specific for cygwin-1.7.  The only differences
between this package and the simultaneously-released gettext-0.17-3
for cygwin-1.5 are (1) compiled against the cygwin-1.7 DLL and its
import library, and (2) documentation changes.

COMPILER USED: gcc-3.4.4-3 and g++-3.4.4-3
This is important to note, because libasprintf0 is a C++ library. Later
updates MAY use gcc-4.3, but will be accompanied by DLL version number
bumps for all C and C++ dlls.

These packages should be updated together with libiconv 1.12-10:

    libiconv-1.12-10
    libiconv2-1.12-10
    libcharset1-1.12-10

    gettext-0.17-10
    gettext-devel-0.17-10
    libintl8-0.17-10
    libgettextpo0-0.17-10
    libasprintf0-0.17-10

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 DOT com AT cygwin DOT 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/