This is the mail archive of the cygwin-announce@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

New on sourceware: gettext-0.10.35-2


gettext is now available on sourceware.  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.

INSTALLATION:

To update your installation, click on the "Install Cygwin now" link on
the http://sources.redhat.com/cygwin web page.  This downloads setup.exe
to your system.

Run setup and answer all of the questions.  PLEASE, PLEASE, PLEASE
choose a mirror site for your download.  The 'sources.redhat.com' site
is badly overloaded.  The mirrors below have the latest version of this
package:

ftp://ftp.sunsite.utk.edu/pub/cygwin/ (US)
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/mirrors/cygnus/
(Germany)
ftp://ftp.ntua.gr/pub/pc/cygwin/ (Greece)

The setup.exe program will figure out what needs to be updated on your
system and should install the less package automatically.

If you have questions or comments, please send them to the Cygwin
mailing list at:  cygwin@sources.redhat.com .  I would appreciate if you
would use this mailing list rather than emailing me directly. This
includes ideas and comments about the setup utility or Cygwin general.

If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe to 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@sources.redhat.com


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 I also made available a gettext-0.10.35-1 package on sourceware
(announcement here:
http://www.cygwin.com/ml/cygwin-apps/2000-08/msg00050.html) but that one
used the name 'libintl.dll' for the shared lib, instead of
'cygintl.dll'.

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/cygintl.dll (**)
  - cygwin-specific docs in /usr/doc/Cygwin/gettext-0.10.35.README
  
(**) The last update to gettext was in April 1999, over 1.5 yrs ago. 
This interface is not in immediate danger of changing.  No versioning
necessary.

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 It is probably best to specify '--use-included-gettext' and NOT use
this package when building gcc.  It is also probably best to use the
naked-intl package when building dumper.exe (part of the cygwin kernel
build) and NOT use this package.  Those two packages (gcc and
cygwin1.dll) are fairly complex, and it's difficult to get them behave
nicely when linking to this package.  Other packages, however, do build
/ link with this gettext package with greater ease. 

-- Chuck



------- LIBTOOL DIGRESSION ---------

<disclaimer: there is lots of work going on in the libtool package right
now, so that the following analysis may soon be out-of-date and
incorrect.  I'm just describing how things are *now* and *my*
experience. No flames, please>

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

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

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

------- END LIBTOOL DIGRESSION ------------

------- AUTOCONF / AUTOMAKE DIGRESSION ----------

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 from scratch without those tools just to test). 

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

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 it to 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 AUTOCONF / AUTOMAKE DIGRESSION ----------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]