Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <39A9ABE9.ED344C19@ece.gatech.edu>
Date: Sun, 27 Aug 2000 20:01:45 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: cygwin-apps AT sourceware DOT cygnus DOT com
Subject: gettext-0.10.35-1 available for test
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

gettext is the GNU package which provides 'national language support'
for other programs. It includes a number of utility programs as well as
a library, libintl, that can be linked to your own programs.

It can be downloaded from:

ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/
  gettext-0.10.35-1-src.tar.gz
  gettext-0.10.35-1.tar.gz

--OR--

http://cygutils.netpedia.net/gettext-0.10.35-1-src.tar.gz
http://cygutils.netpedia.net/gettext-0.10.35-1.tar.gz

Comments and test reports eagerly awaited.

NOTES:

o Building the package from source requires gcc-2.95.2-2 and
binutils-20000722-1 or later

o I've had gettext-0.10.35 on cygutils for some time, but the cygutils
version was staticlib only, and didn't follow the official cygwin
package layout rules.

o The package includes several utilities.  These utilities are
*statically* linked, although this package does include a dynamic lib
(dll) and the associated import lib.  I just didn't link the utilities
dynamically  (see below for explanation).

o Abides by the cygwin package system standard:
  - import-lib   /usr/lib/libintl.dll.a
  - static-lib   /usr/lib/libintl.a
  - stripped dll /usr/bin/libintl.dll
  - cygwin-specific docs in /usr/doc/Cygwin/gettext-0.10.35.README
  
o A cygwin-specific README and PATCH are stored in the source archive,
under <top>/CYGWIN-PATCHES/* (although that patch has already been
applied to the archive itself). The cygwin-specific README is also
installed by the binary distribution as described above.

o If you are building a package that depends on gettext (that is, on
libintl) and you wish to link *statically*, define -DGETTEXT_STATIC to
get the 'correct' #define's in libintl.h when compiling the .o files in
your package. Also, use 'gcc -static' when linking your package.

o No special -Ddefine options or link options are needed when building a
package that depends on gettext (that is, on libintl) and you want to
link dynamically (recommended). 

o There has been comment on the list recently that some program, which
is a part of the cygwin kernel build process, depends on gettext
(libintl). I am unsure as to how installing this package may impact
kernel builds. It's just a single optional program, dumper.exe -- best
case, dumper.exe can now be built but will inherit an external,
dynamically linked dependency on libintl.dll.

----------------------------

Okay, so why did I link the utility programs statically?  Because
libtool is just too smart. When you libtool-ize a package, as gettext
is, then when configure determines that shared libs are unsupported,
libtool makes it really hard to do-it-yourself.  I managed to make the
minimum necessary changes (*) to support building a working dll, and
hand-linked the utility programs myself.  When I did this, I had a set
of dynamically-linked utility programs and they passed all the 'make
check' tests. However, this required manual intervention.  I couldn't
get the build process to link the utility programs dynamically on its
own.  So, I just let it do its own thing and link them statically (and I
*was* able to make a few changes so *that*, at least, went smoothly).

(*) patch is 160kB, but most of the changes are autogenerated stuff from
automake [[[ note about autoconf/automake -- see very bottom ]]]

----This does NOT mean that it's a bad idea to link your external
program, which depends on libintl, dynamically.  On the contrary, I
encourage you to do just that.  It's merely that *inside* the gettext
package, it's hard to convince libtool/autoconf/automake to do it the
right way.  *Outside* the gettext package, it's a piece of cake.----

The "Right Thing" (TM) is to fix libtool so that it handles dll's. But
libtool, AFAICT, only understands the unix way:
  1) do special stuff when building a shared library
  2) compiling an object which depends on a shared library is treated
exactly the same as if it depended on a static library
  3) linking 'just works'; handled by ld, shared libs are preferred, but
you can force a link to a static lib by using '-static'.  However,
libtool doesn't do that.

In a package like gettext, where there is an internal library and
executables which depend on that library, libtool links this way:
  gcc -o foo.exe ../intl/libintl.a foo.o bar.o baz.o bungle.o
Note the explicit reliance on "libintl.a" as opposed to "-L../intl
-lintl"?  Libtool won't do the second one -- which is required if you
want to be able to use the -Bstatic/-Bdynamic linker options. Worse, you
can't just tell libtool to use "../intl/libintl.dll.a" because it 'just
knows' what library dependencies to use.  Even worse, you can't ever use
relative paths with libtool, so "-L../intl" is out.

Thanks to work by DJ, myself, and others over the past year and more,
number 3) above is true on the cygwin platform. #1) isn't necessarily
required unless you are exporting DATA from the dll, but...you probably
should do declspec(dllexport) if you want to strictly correct about it. 
Ditto for #2) -- unless DATA items are involved, you don't really *need*
to do anything special, but you probably should use declspec(dllimport)
to be strictly correct.

So, libtool just doesn't do dll's. It will take a lot of work to make it
do so. In the meantime, I'm still dll-izing libraries the hard way.

Anyway, see the CYGWIN-PATCHES/gettext-0.10.35.README for more
information.

--Chuck

autoconf/automake:  gettext can be built without autoconf/automake. I
built it *with* those tools, so that the Makefile.in's and whatnot are
all uptodate (I even removed autoconf/automake and rebuilt
gettext-0.10.35-1 from scratch without those tools just to test). 

HOWEVER, I couldn't use Michael Ring's versions of autoconf/automake. 
The gettext configure report

checking for working aclocal... missing
checking for working autoconf... found
checking for working automake... missing
checking for working autoheader... found
checking for working makeinfo... found

So, to get update all the makefile.in's, I had to remove Michael's
versions and revert to the ones from cygutils. I did not investigate
further, but the cygutils versions worked: 

checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found

Now, this doesn't mean you can't build gettext without *my* cygutils
autoconf/automake packages. You can build gettext without ANY
autoconf/automake. I'm just reporting a failure in Michael's packages
(hopefully he's reading this bit...)

---END---