Mail Archives: cygwin/2001/12/19/00:33:04
This one is fixed by the new gettext/libintl packages too. (At least,
I'm pretty sure it is.)
--Chuck
Charles Wilson wrote:
> Mark Paulus wrote:
>
>> Thanks, that worked. But, it makes me confused.
>> When I build this particular app under linux/debian,
>> it does NOT have the -lintl linker flag. And when I add
>> it, the link fails. But under cygwin, I need it.
>> Can anyone out there help me reconcile the issues here.
>> (So I can go back to the source and either provide a patch,
>> or do whatever to get it to work in both environs).
>>
>> Thanks.
>
>
>
> Take a close look at the output from the configure script. Many
> packages include a copy of the source for gettext (libintl) within their
> own source distribution. If configure can't find a system library for
> it, it'll use the included source (some packages ALWAYS use the included
> source unless explicitly instructed to use the system version).
>
> However, most autotool based packages treat the included gettext as a
> "convenience library" which means that IF using the included gettext, it
> doesn't link it via "-lintl" -- instead, it links in using a direct
> reference to the static lib: "myobj.o otherobj.o
> ../gettext/intl/.libs/libintl.a moreobjs.o".
>
> If you add ANOTHER gettext library to the same link command (e.g.
> ../gettext/intl/.libs/libintl.a -lintl) you'll get duplicate symbol
> definition and the link will fail.
>
> That's in an ideal world (linux). On cygwin, the -lintl will find the
> dll import library (with lots of __imp__foo symbols) but the
> ../gettext/intl/.libs/libintl.a is a static library and only has _foo
> symbols. Therefore, on cygwin, you CAN include both without error --
> because there IS no symbol duplication. (Of course, since your object
> files are only looking for the __imp__foo symbols, the
> ../get..../libintl.a is not used, even though it's specified.) Welcome
> to Windows.
>
> On cygwin, there are two possibilities:
>
> 1) configure DOES find the system gettext library so it does NOT build
> the included version. However (and here's the broken part) it neglects
> to add -lintl to the generated link line.
>
> or
>
> 2) configure decides to go ahead an build the included gettext. And
> links against it using the ../gettext/intl/.libs/libintl.a method. BUT:
> for whatever reason, the *compilation* stage of the OTHER object files
> are using the SYSTEM header files (/usr/include/gettext.h & friends) and
> NOT the included header files (../gettext/include/*).
>
> These are different. The SYSTEM header files assume you're going to
> link against a DLL (thus, __imp__foo). The locally included header
> files don't know anything about DLL's -- so they only declare the _foo
> symbols. not __imp__foo). Plus, the gettext library built from the
> included sources is a static lib, so it doesn't have __imp__foo symbols,
> only _foo symbols.
>
> the problem here is twofold:
> a) system gettext headers different from "standard" gettext headers.
> This is unavoidable (for now) because of the whole DLL problem.
> b) the package is using the system gettext headers when compiling its
> local objects, EVEN WHEN using the local version of gettext.
>
> Solution:
> a) workaround: Use "CFLAGS=-DGETTEXT_STATIC ./configure" (this turns
> the system gettext headers back into the "normal" gettext version).
>
> b) convince your package that it ought to use its own headers when
> using its own internal libraries, and not allow system overrides. I'm
> not sure exactly how to do this -- especially since EVERYTHING in this
> message is guesswork, because you didn't provide a whole lot of
> information. "Problem building 'program':" "This particular app" etc.
> A bit light on details, wouldn't you say? I'm not even sure your app
> is autotooled, or if it really does include its own gettext source. I'm
> just going by the common problems with gettext that have cropped up in
> the past.
>
> c) fix windows/cygwin dll process so that header-file hacks are no
> longer necessary; build and release a new gettext package. (This is my
> job; i'll get to it eventually once the binutils changes/problems are
> fixed)
>
> --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/
- Raw text -