Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Message-ID: <3C202644.9010807@ece.gatech.edu>
Date: Wed, 19 Dec 2001 00:31:48 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
CC: Mark Paulus <commpg AT yahoo DOT com>, "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: problem building program:  undef ref _imp__gettext
References: <200108271752 DOT f7RHqGg23970 AT mail DOT ee DOT gatech DOT edu> <3B8A8E02 DOT 7010000 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/