Re: Confused by gettext on cygwin

Re: Confused by gettext on cygwin

[Charles S. Wilson]

This is a good question, but it should be on list.  I've redirected this 
email to the list.  See below for commentary.

Linus Tolke Y wrote:

> Hi there!
> 
> I have a couple of hobby projects that I am trying to run with the gnu 
> tools (autoconf, automake, gettext...) to learn these tools. 
> 
> This week I tried to move the developing environment from Linux to
> cygwin since I don't have Linux installed on my laptop.
> 
> After checking out my project from cvs I run the gettextize command to
> get all the intl-files in place and what confused me was that the
> result of the gettextize command was different in Linux and in cygwin.
> Looking at the file intl/gettext.h that was created by gettextize, the
> file created in cygwin included some stuff within 
> #if defined(__CYGWIN__)
> #endif
> The version of gettextize was the same on both the cygwin and Linux
> systems.
> [lyskom@linus intl]$ gettextize --version
> /usr/bin/gettextize (GNU gettext) 0.10.35
> Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> Written by Ulrich Drepper
> [lyskom@linus intl]$
> 
> What is the purpose of modifying these files for cygwin in this way?


Well, the gettext.h created by gettextize is made as a copy of a special 
gettext.h stored in /usr/share/gettext/intl/.  During my build process 
for cygwin, the /usr/share/gettext/intl/gettext.h file is created 
identical to the system gettext.h in /usr/include.  So, if the system 
file is different from some baseline, then the created file will also be 
different.

It was necessary to modify gettext.h on cygwin to support using the 
braindead windows shared library format (DLLs).  Functions and variables 
must be declared with special compile-time directives 
(__declspec(dllimport), __declspec(dllexport)) -- thus, the headers must 
be modified.

Now, I have corresponded with the "real" gettext people about this. 
Their response is that these changes are just too damn ugly to 
incorporate -- and there MAY be upcoming changes to GCC and binutils so 
that cygwin no longer requires this uglification.  Therefore, those guys 
are taking a wait-and-see approach.  We all hope that the uglification 
goes away at some point.

> I thought that the purpose of the created files were to generate them
> exactly in the same way independantly of what system they were
> generated on. The are probably not compiled on that system anyway.
> 
> What is it about gettext that I have missunderstood?


Nothing.

If you merely want to gettextize a package that will be built on another 
platform, or will be built on cygwin ALWAYS using the 
--with-included-gettext (that is, you'll never use the cygwin system 
libintl.a with your package), then just

copy the "linux" or "official" gettext.h into /usr/share/gettext/intl on 
your cygwin system.  In fact, that may not be a bad idea in ALL cases, 
because if somebody builds your package on cygwin and DOESN't specify 
--with-included-gettext, then the build will use the 
/usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your 
"official" gettextized gettext.h won't even get used in that case.

Hmmm...perhaps the cygwin gettext package should put the official 
gettext.h into /usr/share/gettext/intl, and only use the modified, 
DLL-supporting gettext.h for /usr/include...

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Confused by gettext on cygwin

[Linus Tolke Y]

>Date: Wed, 04 Jul 2001 21:09:20 -0400
>From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
>
...
>Well, the gettext.h created by gettextize is made as a copy of a special 
>gettext.h stored in /usr/share/gettext/intl/.  During my build process 
>for cygwin, the /usr/share/gettext/intl/gettext.h file is created 
>identical to the system gettext.h in /usr/include.  So, if the system 
>file is different from some baseline, then the created file will also be 
>different.
>
>It was necessary to modify gettext.h on cygwin to support using the 
>braindead windows shared library format (DLLs).  Functions and variables 
>must be declared with special compile-time directives 
>(__declspec(dllimport), __declspec(dllexport)) -- thus, the headers must 
>be modified.
>
>Now, I have corresponded with the "real" gettext people about this. 
>Their response is that these changes are just too damn ugly to 
>incorporate -- and there MAY be upcoming changes to GCC and binutils so 
>that cygwin no longer requires this uglification.  Therefore, those guys 
>are taking a wait-and-see approach.  We all hope that the uglification 
>goes away at some point.
>
>> I thought that the purpose of the created files were to generate them
>> exactly in the same way independantly of what system they were
>> generated on. The are probably not compiled on that system anyway.
>> 
>> What is it about gettext that I have missunderstood?
>
>
>Nothing.
>
>If you merely want to gettextize a package that will be built on another 
>platform, or will be built on cygwin ALWAYS using the 
>--with-included-gettext (that is, you'll never use the cygwin system 
>libintl.a with your package), then just
>
>copy the "linux" or "official" gettext.h into /usr/share/gettext/intl on 
>your cygwin system.  In fact, that may not be a bad idea in ALL cases, 
>because if somebody builds your package on cygwin and DOESN't specify 
>--with-included-gettext, then the build will use the 
>/usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your 
>"official" gettextized gettext.h won't even get used in that case.
>
>Hmmm...perhaps the cygwin gettext package should put the official 
>gettext.h into /usr/share/gettext/intl, and only use the modified, 
>DLL-supporting gettext.h for /usr/include...

I think your conclusion is appealing. As I see it the gettext package
should be regarded as a package with two different purposes.

1. The purpose of providing the gettext library and directories on a
   system where it is installed.
2. The purpose of providing every package internationalized with GNU
   gettext with the necessary files consistantly and identically.

My observation is that in this case is that the purpose 1 on a
cygwin-system has infected the purpose 2.

I think the best thing would be if the gettextize command include
non-modified files i.e. directly from the gettext distribution
(exactly as the gettextize command would do on all other systems).

If there are problems getting the purpose 1 right on a system, like
the special DLL-requirements you are talking about, then that would
perhaps complicated purpose 1 but that should never modify purpose 2.

	/Linus

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Confused by gettext on cygwin

[Charles Wilson]

AANNNDDD this one should be fixed now, too.

--Chuck


Linus Tolke Y wrote:

>>Date: Wed, 04 Jul 2001 21:09:20 -0400
>>From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
>>
> ...
> 
>>Well, the gettext.h created by gettextize is made as a copy of a special 
>>gettext.h stored in /usr/share/gettext/intl/.  During my build process 
>>for cygwin, the /usr/share/gettext/intl/gettext.h file is created 
>>identical to the system gettext.h in /usr/include.  So, if the system 
>>file is different from some baseline, then the created file will also be 
>>different.
>>
>>It was necessary to modify gettext.h on cygwin to support using the 
>>braindead windows shared library format (DLLs).  Functions and variables 
>>must be declared with special compile-time directives 
>>(__declspec(dllimport), __declspec(dllexport)) -- thus, the headers must 
>>be modified.
>>
>>Now, I have corresponded with the "real" gettext people about this. 
>>Their response is that these changes are just too damn ugly to 
>>incorporate -- and there MAY be upcoming changes to GCC and binutils so 
>>that cygwin no longer requires this uglification.  Therefore, those guys 
>>are taking a wait-and-see approach.  We all hope that the uglification 
>>goes away at some point.
>>
>>
>>>I thought that the purpose of the created files were to generate them
>>>exactly in the same way independantly of what system they were
>>>generated on. The are probably not compiled on that system anyway.
>>>
>>>What is it about gettext that I have missunderstood?
>>>
>>
>>Nothing.
>>
>>If you merely want to gettextize a package that will be built on another 
>>platform, or will be built on cygwin ALWAYS using the 
>>--with-included-gettext (that is, you'll never use the cygwin system 
>>libintl.a with your package), then just
>>
>>copy the "linux" or "official" gettext.h into /usr/share/gettext/intl on 
>>your cygwin system.  In fact, that may not be a bad idea in ALL cases, 
>>because if somebody builds your package on cygwin and DOESN't specify 
>>--with-included-gettext, then the build will use the 
>>/usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your 
>>"official" gettextized gettext.h won't even get used in that case.
>>
>>Hmmm...perhaps the cygwin gettext package should put the official 
>>gettext.h into /usr/share/gettext/intl, and only use the modified, 
>>DLL-supporting gettext.h for /usr/include...
>>
> 
> I think your conclusion is appealing. As I see it the gettext package
> should be regarded as a package with two different purposes.
> 
> 1. The purpose of providing the gettext library and directories on a
>    system where it is installed.
> 2. The purpose of providing every package internationalized with GNU
>    gettext with the necessary files consistantly and identically.
> 
> My observation is that in this case is that the purpose 1 on a
> cygwin-system has infected the purpose 2.
> 
> I think the best thing would be if the gettextize command include
> non-modified files i.e. directly from the gettext distribution
> (exactly as the gettextize command would do on all other systems).
> 
> If there are problems getting the purpose 1 right on a system, like
> the special DLL-requirements you are talking about, then that would
> perhaps complicated purpose 1 but that should never modify purpose 2.
> 
> 	/Linus
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Confused by gettext on cygwin

[Linus Tolke]

Hello Chuck!

Thanks for taking this further. I now succeeded in building my project i.e.
the "make" and "make dist" works. I can even unpack the distribution and
build.

I am still not satisfied though. ;-)

Here is the new and more sofisticated problem.

1. I build my project (make)
2. I build the distribution of my project (make dist)
3. I move the distribution (file tty-client-0.13.alfa.7.tar.gz) to a Solaris
2.7 system.
4. I unpack and run configure on the Solaris 2.7 system.
5. When I run make on the Solaris system it fails in the intl directory.

I interpret this to mean that the version of gettext provided by cygwin is
not as portable as it should be. Remember that this worked before I moved my
development environment to cygwin/autoconf-2.

Here is the error message that the compiler (linker) gives me:
make[2]: Leaving directory
`/tmp/linus_tty-client/tty-client-0.13.alfa.7/librari
es'
Making all in intl
make[2]: Entering directory
`/tmp/linus_tty-client/tty-client-0.13.alfa.7/intl'
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   intl-compat.c
In file included from intl-compat.c:21:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   bindtextdom.c
In file included from bindtextdom.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   dcgettext.c
In file included from dcgettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   dgettext.c
In file included from dgettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   gettext.c
In file included from gettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   finddomain.c
In file included from finddomain.c:21:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   loadmsgcat.c
In file included from loadmsgcat.c:27:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   localealias.c
In file included from localealias.c:27:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   textdomain.c
In file included from textdomain.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   l10nflist.c
In file included from l10nflist.c:27:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   explodename.c
In file included from explodename.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   dcigettext.c
In file included from dcigettext.c:27:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   dcngettext.c
In file included from dcngettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   dngettext.c
In file included from dngettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   ngettext.c
In file included from ngettext.c:20:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   plural.c
In file included from plural.y:30:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/lo
cal/
share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../int
l  -
g -O2   localcharset.c
In file included from localcharset.c:23:
../config.h:247: warning: `LOCALEDIR' redefined
*Initialization*:1: warning: this is the location of the previous definition
rm -f cygintl-1.dll
gcc -shared -Wl,--export-all-symbols -Wl,--out-implib=libintl.dll.a
intl-compat.
o bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o
local
ealias.o textdomain.o l10nflist.o explodename.o dcigettext.o dcngettext.o
dngett
ext.o ngettext.o plural.o localcharset.o -o cygintl-1.dll
/usr/ccs/bin/ld: illegal option -- -
/usr/ccs/bin/ld: illegal option -- -
ld: warning: option -o appears more than once, first setting taken
usage: ld [-abd:e:f:h:il:mo:rstu:z:B:D:F:GI:L:M:N:Q:R:S:VY:] file(s)
        [-a]            create an absolute file
        [-b]            do not do special PIC relocations in a.out
        [-d y|n]        operate in dynamic|static mode
        [-e sym]        use `sym' as entry point address
        [-f name]       specify library for which this file is an auxiliary
                        filter
        [-h name]       use `name' as internal shared object identifier
        [-i]            ignore LD_LIBRARY_PATH setting
        [-l x]          search for libx.so or libx.a
        [-m]            print memory map
        [-o outfile]    name the output file `outfile'
        [-r]            create a relocatable object
        [-s]            strip any symbol and debugging information
        [-t]            do not warn of multiply defined symbols of different
                        sizes
        [-u sym]        create an undefined symbol `sym'
        [-z absexec]    when building an executable absolute symbols
                        referenced in dynamic objects are promoted to
                        the executable.
        [-z now]        mark object as requiring non-lazy binding
        [-z defs|nodefs]
                        disallow|allow undefined symbols
        [-z direct]     specify 'direct' bindings for executable when run
        [-z groupperm|nogroupperm]
                        enable|disable setting of GROUP permissions
                        on dynamic dependencies
        [-z ignore|record]
                        ignore|record unused dynamic dependencies
        [-z initfirst]  mark object so the .init section
                        of this object is executed before the .init section
                        of other objects
        [-z loadfltr]   mark filter as requiring immediate loading of its
                        filtees at runtime
        [-z interpose]  dynamic object is to be an `interposer' on
                        direct bindings
        [-z lazyload|nolazyload]
                        enable|disable delayed loading of shared objects
        [-z muldefs]    allow multiply defined symbols
        [-z nodelete]   mark object as non-deletable
        [-z nodlopen]   mark object as non-dlopen()'able
        [-z noversion]  don't record any version sections
        [-z origin]     mark object as requiring $ORIGIN processing
        [-z redlocsym]  reduce local syms in .symtab to a minimum
        [-z text]       disallow output relocations against text
        [-z textwarn]   warn if there are relocations against text
        [-z textoff]    allow output relocations against text
        [-z weakextract]
                        allow extraction of archive members to resolve weak


	/Linus

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: den 19 december 2001 06:33
> To: Linus Tolke Y
> Cc: cygwin@cygwin.com
> Subject: Re: Confused by gettext on cygwin
>
>
> AANNNDDD this one should be fixed now, too.
>
> --Chuck
>
>
> Linus Tolke Y wrote:
>
> >>Date: Wed, 04 Jul 2001 21:09:20 -0400
> >>From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
> >>
> > ...
> >
> >>Well, the gettext.h created by gettextize is made as a copy of
> a special
> >>gettext.h stored in /usr/share/gettext/intl/.  During my build process
> >>for cygwin, the /usr/share/gettext/intl/gettext.h file is created
> >>identical to the system gettext.h in /usr/include.  So, if the system
> >>file is different from some baseline, then the created file
> will also be
> >>different.
> >>
> >>It was necessary to modify gettext.h on cygwin to support using the
> >>braindead windows shared library format (DLLs).  Functions and
> variables
> >>must be declared with special compile-time directives
> >>(__declspec(dllimport), __declspec(dllexport)) -- thus, the
> headers must
> >>be modified.
> >>
> >>Now, I have corresponded with the "real" gettext people about this.
> >>Their response is that these changes are just too damn ugly to
> >>incorporate -- and there MAY be upcoming changes to GCC and binutils so
> >>that cygwin no longer requires this uglification.  Therefore,
> those guys
> >>are taking a wait-and-see approach.  We all hope that the uglification
> >>goes away at some point.
> >>
> >>
> >>>I thought that the purpose of the created files were to generate them
> >>>exactly in the same way independantly of what system they were
> >>>generated on. The are probably not compiled on that system anyway.
> >>>
> >>>What is it about gettext that I have missunderstood?
> >>>
> >>
> >>Nothing.
> >>
> >>If you merely want to gettextize a package that will be built
> on another
> >>platform, or will be built on cygwin ALWAYS using the
> >>--with-included-gettext (that is, you'll never use the cygwin system
> >>libintl.a with your package), then just
> >>
> >>copy the "linux" or "official" gettext.h into
> /usr/share/gettext/intl on
> >>your cygwin system.  In fact, that may not be a bad idea in ALL cases,
> >>because if somebody builds your package on cygwin and DOESN't specify
> >>--with-included-gettext, then the build will use the
> >>/usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your
> >>"official" gettextized gettext.h won't even get used in that case.
> >>
> >>Hmmm...perhaps the cygwin gettext package should put the official
> >>gettext.h into /usr/share/gettext/intl, and only use the modified,
> >>DLL-supporting gettext.h for /usr/include...
> >>
> >
> > I think your conclusion is appealing. As I see it the gettext package
> > should be regarded as a package with two different purposes.
> >
> > 1. The purpose of providing the gettext library and directories on a
> >    system where it is installed.
> > 2. The purpose of providing every package internationalized with GNU
> >    gettext with the necessary files consistantly and identically.
> >
> > My observation is that in this case is that the purpose 1 on a
> > cygwin-system has infected the purpose 2.
> >
> > I think the best thing would be if the gettextize command include
> > non-modified files i.e. directly from the gettext distribution
> > (exactly as the gettextize command would do on all other systems).
> >
> > If there are problems getting the purpose 1 right on a system, like
> > the special DLL-requirements you are talking about, then that would
> > perhaps complicated purpose 1 but that should never modify purpose 2.
> >
> > 	/Linus
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
>
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Confused by gettext on cygwin

[Charles Wilson]

Linus Tolke wrote:

> Hello Chuck!
> 
> Thanks for taking this further. I now succeeded in building my project i.e.
> the "make" and "make dist" works. I can even unpack the distribution and
> build.
> 
> I am still not satisfied though. ;-)
> 
> Here is the new and more sofisticated problem.
> 
> 1. I build my project (make)
> 2. I build the distribution of my project (make dist)
> 3. I move the distribution (file tty-client-0.13.alfa.7.tar.gz) to a Solaris
> 2.7 system.
> 4. I unpack and run configure on the Solaris 2.7 system.
> 5. When I run make on the Solaris system it fails in the intl directory.
> 
> I interpret this to mean that the version of gettext provided by cygwin is
> not as portable as it should be. Remember that this worked before I moved my
> development environment to cygwin/autoconf-2.
> 
> Here is the error message that the compiler (linker) gives me:

> gcc -shared -Wl,--export-all-symbols -Wl,--out-implib=libintl.dll.a
> intl-compat.
> o bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o
> local
> ealias.o textdomain.o l10nflist.o explodename.o dcigettext.o dcngettext.o
> dngett
> ext.o ngettext.o plural.o localcharset.o -o cygintl-1.dll
> /usr/ccs/bin/ld: illegal option -- -
> /usr/ccs/bin/ld: illegal option -- -
> ld: warning: option -o appears more than once, first setting taken

Remember, the (now) current version of gettext for cygwin is only 
*partially* migrated over to libtool.  It looks as tho the parts that 
*aren't* are causing a problem on other platforms.  Therefore, the 
"full" correction to this problem will probably have to wait until:

a) we're happy with the current cygwin/libtool port
b) we get the nifty libtool changes pushed into the REAL libtool
c) we ensure that the REAL libtool (which includes our changes) works 
okay on cygwin
d) I *fully* re-libtoolize gettext using the new (REAL) libtool
e) We push the re-libtoolized version to the upstream gettext folks.

THEN, your problems should go away -- but as you can see, it'll be a 
long process.  I'm sorry, but shared libs on windows just plain suck.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Confused by gettext on cygwin

[Charles S. Wilson]

Robert Collins wrote:

>>-----Original Message-----
>>From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
>>copy the "linux" or "official" gettext.h into 
>>/usr/share/gettext/intl on 
>>your cygwin system.  In fact, that may not be a bad idea in 
>>ALL cases, 
>>because if somebody builds your package on cygwin and DOESN't specify 
>>--with-included-gettext, then the build will use the 
>>/usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your 
>>"official" gettextized gettext.h won't even get used in that case.
>>
>>Hmmm...perhaps the cygwin gettext package should put the official 
>>gettext.h into /usr/share/gettext/intl, and only use the modified, 
>>DLL-supporting gettext.h for /usr/include...
>>
>>
> 
> Won't that fail to link? (ld finds the .dll not the static archive?)


No, it won't.  Let's consider each case, under the assumption that 
/usr/include/gettext.h is the cygwin-modified, dll-supporting version, 
and /usr/share/gettext/intl/gettext.h is the "official" version.

1) You want to build project "foo" which depends on gettext, and you do 
NOT specify --with-included-gettext (or foo doesn't include an embedded 
copy of the gettext source code).  Then, /usr/include/gettext.h is used, 
and /usr/lib/libintl.dll.a is used.  Since dllimport is the default in 
/usr/include/gettext.h, everything is fine.

1a) You want to build project "foo" which depends on gettext, and you do 
NOT specify --with-included-gettext (or foo doesn't include an embedded 
copy of the gettext source code). BUT, you want to link statically. 
Well, then again, /usr/include/gettext.h is used, but you must specify 
-DGETTEXT_STATIC.  Also, you must specify -static when linking, and then 
/usr/lib/libintl.a will be used (these additional flag requirements are 
"normal" for statically linking system libraries on cygwin)

2) You want to build project "foo" which depends on gettext, and you 
specify --with-included-gettext (and "foo" contains an embedded copy of 
the gettext source code).  Well, configure will set things up so that 
foo/intl is in the -I include path, and in the -L libsearch path before 
the system directories.  Since gettext builds as a static lib OOB, 
foo/intl/libintl.a will build okay, and will get used during the link 
process (ld searches the -L path IN ORDER, checking each directory for 
all possible library names -- libintl.dll.a, libintl.a, etc -- before 
moving to the next directory in the path.  Since foo/intl will precede 
/usr/lib in this configuration, foo/intl/libintl.a will be found before 
/usr/lib/libintl.dll.a).  Okay, so /foo/intl/gettext.h is used during 
compilation, and foo/intl/libintl.a is used during linking -- everything 
is fine.

Note that in cases 1) and 2), /usr/share/gettext/intl/gettext.h isn't 
used.  So it doesn't matter if that file is the cygwin-ized version, the 
official version, or my mother's recipe for broccoli quiche.

3) You want to gettextize a package -- say, "bar".  Well, gettextize 
ought to work the same on every platform.  So, since gettextizing uses 
the gettext.h in /usr/share/gettext/intl/, then that file should match 
the "official" version.  This will create a "bar" package identical to 
the one that would be created if it were gettextized on linux.  And as 
explained in 2), that gettextized "bar" package will build just fine.

Did I miss anything?

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Confused by gettext on cygwin

[Robert Collins]

> -----Original Message-----
> From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
> copy the "linux" or "official" gettext.h into 
> /usr/share/gettext/intl on 
> your cygwin system.  In fact, that may not be a bad idea in 
> ALL cases, 
> because if somebody builds your package on cygwin and DOESN't specify 
> --with-included-gettext, then the build will use the 
> /usr/include/gettext.h and /usr/lib/libintl.a -- so no problems: your 
> "official" gettextized gettext.h won't even get used in that case.
> 
> Hmmm...perhaps the cygwin gettext package should put the official 
> gettext.h into /usr/share/gettext/intl, and only use the modified, 
> DLL-supporting gettext.h for /usr/include...
> 

Won't that fail to link? (ld finds the .dll not the static archive?)

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/