Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B43E62F.2020205@ece.gatech.edu>
Date: Wed, 04 Jul 2001 23:59:43 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Linus Tolke Y <linus AT lysator DOT liu DOT se>, cygwin AT cygwin DOT com
Subject: Re: Confused by gettext on cygwin
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F0E3 AT itdomain002 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

>>-----Original Message-----
>>From: Charles S. Wilson [mailto:cwilson AT ece DOT gatech DOT 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/