From: Charles Wilson <cwilson@ece.gatech.edu>
To: Mark Paulus <commpg@yahoo.com>
Cc: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: problem building program: undef ref _imp__gettext
Date: Mon, 27 Aug 2001 11:14:00 -0000 [thread overview]
Message-ID: <3B8A8E02.7010000@ece.gatech.edu> (raw)
In-Reply-To: <200108271752.f7RHqGg23970@mail.ee.gatech.edu>
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/
next parent reply other threads:[~2001-08-27 11:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200108271752.f7RHqGg23970@mail.ee.gatech.edu>
2001-08-27 11:14 ` Charles Wilson [this message]
2001-08-27 13:51 ` Mark Paulus
2001-08-27 13:51 ` Mark Paulus
2001-12-18 21:33 ` Charles Wilson
[not found] <ITDOMAIN002n20lbhsK0000006f@itdomain002.itdomain.net.au>
2001-08-28 6:49 ` Robert Collins
[not found] <ITDOMAIN002DYjqQMol00000064@itdomain002.itdomain.net.au>
2001-08-27 20:59 ` Robert Collins
2001-08-27 22:04 ` Charles Wilson
2001-08-28 0:14 ` Robert Collins
2001-08-28 6:04 ` Mark Paulus
[not found] <200108271722.f7RHMiN20824@mail.ee.gatech.edu>
2001-08-27 10:42 ` Charles Wilson
2001-08-27 10:49 ` Mark Paulus
2001-08-27 10:22 Mark Paulus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B8A8E02.7010000@ece.gatech.edu \
--to=cwilson@ece.gatech.edu \
--cc=commpg@yahoo.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).