* RE: Confused by gettext on cygwin
@ 2001-07-04 18:35 Robert Collins
2001-07-04 20:59 ` Charles S. Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Robert Collins @ 2001-07-04 18:35 UTC (permalink / raw)
To: Charles S. Wilson, Linus Tolke Y; +Cc: cygwin
> -----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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by gettext on cygwin 2001-07-04 18:35 Confused by gettext on cygwin Robert Collins @ 2001-07-04 20:59 ` Charles S. Wilson 0 siblings, 0 replies; 7+ messages in thread From: Charles S. Wilson @ 2001-07-04 20:59 UTC (permalink / raw) To: Robert Collins; +Cc: Linus Tolke Y, cygwin 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <200107042249.AAA26080@sandra.lysator.liu.se>]
* Re: Confused by gettext on cygwin [not found] <200107042249.AAA26080@sandra.lysator.liu.se> @ 2001-07-04 18:09 ` Charles S. Wilson 2001-07-07 8:35 ` Linus Tolke Y 0 siblings, 1 reply; 7+ messages in thread From: Charles S. Wilson @ 2001-07-04 18:09 UTC (permalink / raw) To: Linus Tolke Y; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by gettext on cygwin 2001-07-04 18:09 ` Charles S. Wilson @ 2001-07-07 8:35 ` Linus Tolke Y 2001-12-18 23:55 ` Charles Wilson 0 siblings, 1 reply; 7+ messages in thread From: Linus Tolke Y @ 2001-07-07 8:35 UTC (permalink / raw) To: cwilson; +Cc: cygwin >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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by gettext on cygwin 2001-07-07 8:35 ` Linus Tolke Y @ 2001-12-18 23:55 ` Charles Wilson 2001-12-29 3:25 ` Linus Tolke 0 siblings, 1 reply; 7+ messages in thread From: Charles Wilson @ 2001-12-18 23:55 UTC (permalink / raw) To: Linus Tolke Y; +Cc: 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Confused by gettext on cygwin 2001-12-18 23:55 ` Charles Wilson @ 2001-12-29 3:25 ` Linus Tolke 2001-12-29 20:16 ` Charles Wilson 0 siblings, 1 reply; 7+ messages in thread From: Linus Tolke @ 2001-12-29 3:25 UTC (permalink / raw) To: Charles Wilson, Linus Tolke Y; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by gettext on cygwin 2001-12-29 3:25 ` Linus Tolke @ 2001-12-29 20:16 ` Charles Wilson 0 siblings, 0 replies; 7+ messages in thread From: Charles Wilson @ 2001-12-29 20:16 UTC (permalink / raw) To: Linus Tolke; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-12-29 20:43 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-04 18:35 Confused by gettext on cygwin Robert Collins 2001-07-04 20:59 ` Charles S. Wilson [not found] <200107042249.AAA26080@sandra.lysator.liu.se> 2001-07-04 18:09 ` Charles S. Wilson 2001-07-07 8:35 ` Linus Tolke Y 2001-12-18 23:55 ` Charles Wilson 2001-12-29 3:25 ` Linus Tolke 2001-12-29 20:16 ` Charles Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).