* Re: problem building program: undef ref _imp__gettext [not found] <200108271722.f7RHMiN20824@mail.ee.gatech.edu> @ 2001-08-27 10:42 ` Charles Wilson 2001-08-27 10:49 ` Mark Paulus 0 siblings, 1 reply; 12+ messages in thread From: Charles Wilson @ 2001-08-27 10:42 UTC (permalink / raw) To: Mark Paulus; +Cc: cygwin Mark Paulus wrote: > Hi, > > I'm trying to compile/link a program, and I'm getting the following > undefined reference: _imp__gettext. > > Is there some Environment variable, or something special I need to > do to enable gettext?? add -lintl to your link command. >(BTW, where is the '_imp_' getting > pre-pended to the name anyway??) That's the way shared libraries on windows (DLLs) work. --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] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 10:42 ` problem building program: undef ref _imp__gettext Charles Wilson @ 2001-08-27 10:49 ` Mark Paulus 0 siblings, 0 replies; 12+ messages in thread From: Mark Paulus @ 2001-08-27 10:49 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin 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. On Mon, 27 Aug 2001 13:41:58 -0400, Charles Wilson wrote: >Mark Paulus wrote: > >> Hi, >> >> I'm trying to compile/link a program, and I'm getting the following >> undefined reference: _imp__gettext. >> >> Is there some Environment variable, or something special I need to >> do to enable gettext?? > > >add -lintl to your link command. > >>(BTW, where is the '_imp_' getting >> pre-pended to the name anyway??) > > >That's the way shared libraries on windows (DLLs) work. > > >--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/ -- 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] 12+ messages in thread
[parent not found: <ITDOMAIN002n20lbhsK0000006f@itdomain002.itdomain.net.au>]
* Re: problem building program: undef ref _imp__gettext [not found] <ITDOMAIN002n20lbhsK0000006f@itdomain002.itdomain.net.au> @ 2001-08-28 6:49 ` Robert Collins 0 siblings, 0 replies; 12+ messages in thread From: Robert Collins @ 2001-08-28 6:49 UTC (permalink / raw) To: Mark Paulus; +Cc: cygwin On 28 Aug 2001 07:04:19 -0600, Mark Paulus wrote: > If you have something, please send it on. I am/have opened > a project on sourceforge (debian-cygwin), and will endeavour > to learn more about sourceforge as well as cygwin as well as > debian in this whole process. > I'll dig up what I've got sometime this week, or early next. If I have time I'll get it compiling against HEAD again before I send it on. 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] 12+ messages in thread
[parent not found: <ITDOMAIN002DYjqQMol00000064@itdomain002.itdomain.net.au>]
* Re: problem building program: undef ref _imp__gettext [not found] <ITDOMAIN002DYjqQMol00000064@itdomain002.itdomain.net.au> @ 2001-08-27 20:59 ` Robert Collins 2001-08-27 22:04 ` Charles Wilson 2001-08-28 6:04 ` Mark Paulus 0 siblings, 2 replies; 12+ messages in thread From: Robert Collins @ 2001-08-27 20:59 UTC (permalink / raw) To: Mark Paulus; +Cc: cygwin mailing list On 27 Aug 2001 14:51:05 -0600, Mark Paulus wrote: > Ok, I am guilty as charged of the "minimilistic" information. > I am trying to build the debian dpkg source package, in an > effort to start a debian-cygwin project. dpkg does use > autoconf, and as such, I ran it in it's default state. I will > try re-running it with the pointers you gave me, and then > see about what it takes to get it to build OOB. dpkg requires fifo's last I looked at it. You need to create proper fifos for cygwin _before_ worrying about the package per se. I'm happy to send a patch for cygwin that has partially functioning fifos, but it's quite bitrotted now, and had problems with fork when I last looked at it. 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] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 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 1 sibling, 1 reply; 12+ messages in thread From: Charles Wilson @ 2001-08-27 22:04 UTC (permalink / raw) To: Robert Collins; +Cc: Mark Paulus, cygwin mailing list Robert Collins wrote: > On 27 Aug 2001 14:51:05 -0600, Mark Paulus wrote: > >>Ok, I am guilty as charged of the "minimilistic" information. >>I am trying to build the debian dpkg source package, in an >>effort to start a debian-cygwin project. dpkg does use >>autoconf, and as such, I ran it in it's default state. I will >>try re-running it with the pointers you gave me, and then >>see about what it takes to get it to build OOB. >> > > dpkg requires fifo's last I looked at it. > > You need to create proper fifos for cygwin _before_ worrying about the > package per se. > > I'm happy to send a patch for cygwin that has partially functioning > fifos, but it's quite bitrotted now, and had problems with fork when I > last looked at it. don't you need a daemon to handle permissions for fifos to work? Or am I confusing that with something else? --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] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 22:04 ` Charles Wilson @ 2001-08-28 0:14 ` Robert Collins 0 siblings, 0 replies; 12+ messages in thread From: Robert Collins @ 2001-08-28 0:14 UTC (permalink / raw) To: Charles Wilson; +Cc: Mark Paulus, cygwin mailing list On 28 Aug 2001 01:04:12 -0400, Charles Wilson wrote: > Robert Collins wrote: > > > On 27 Aug 2001 14:51:05 -0600, Mark Paulus wrote: > > > >>Ok, I am guilty as charged of the "minimilistic" information. > >>I am trying to build the debian dpkg source package, in an > >>effort to start a debian-cygwin project. dpkg does use > >>autoconf, and as such, I ran it in it's default state. I will > >>try re-running it with the pointers you gave me, and then > >>see about what it takes to get it to build OOB. > >> > > > > dpkg requires fifo's last I looked at it. > > > > You need to create proper fifos for cygwin _before_ worrying about the > > package per se. > > > > I'm happy to send a patch for cygwin that has partially functioning > > fifos, but it's quite bitrotted now, and had problems with fork when I > > last looked at it. > > > don't you need a daemon to handle permissions for fifos to work? Or am I > confusing that with something else? The daemon is _needed_ for improving some security aspects. It's also _needed_ for shm to work properly. Coincidentally it makes things like fifos a lot easier, because you can potentially just pass around a pair of pipe() handles, rather than the mucking around with mapped memory regions I'm doing at the moment. 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] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 20:59 ` Robert Collins 2001-08-27 22:04 ` Charles Wilson @ 2001-08-28 6:04 ` Mark Paulus 1 sibling, 0 replies; 12+ messages in thread From: Mark Paulus @ 2001-08-28 6:04 UTC (permalink / raw) To: cygwin If you have something, please send it on. I am/have opened a project on sourceforge (debian-cygwin), and will endeavour to learn more about sourceforge as well as cygwin as well as debian in this whole process. On 28 Aug 2001 13:46:46 +1000, Robert Collins wrote: >On 27 Aug 2001 14:51:05 -0600, Mark Paulus wrote: >> Ok, I am guilty as charged of the "minimilistic" information. >> I am trying to build the debian dpkg source package, in an >> effort to start a debian-cygwin project. dpkg does use >> autoconf, and as such, I ran it in it's default state. I will >> try re-running it with the pointers you gave me, and then >> see about what it takes to get it to build OOB. > >dpkg requires fifo's last I looked at it. > >You need to create proper fifos for cygwin _before_ worrying about the >package per se. > >I'm happy to send a patch for cygwin that has partially functioning >fifos, but it's quite bitrotted now, and had problems with fork when I >last looked at it. > >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] 12+ messages in thread
[parent not found: <200108271752.f7RHqGg23970@mail.ee.gatech.edu>]
* Re: problem building program: undef ref _imp__gettext [not found] <200108271752.f7RHqGg23970@mail.ee.gatech.edu> @ 2001-08-27 11:14 ` Charles Wilson 2001-08-27 13:51 ` Mark Paulus ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Charles Wilson @ 2001-08-27 11:14 UTC (permalink / raw) To: Mark Paulus; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 11:14 ` Charles Wilson @ 2001-08-27 13:51 ` Mark Paulus 2001-08-27 13:51 ` Mark Paulus 2001-12-18 21:33 ` Charles Wilson 2 siblings, 0 replies; 12+ messages in thread From: Mark Paulus @ 2001-08-27 13:51 UTC (permalink / raw) To: cygwin mailing list; +Cc: cygwin Ok, I am guilty as charged of the "minimilistic" information. I am trying to build the debian dpkg source package, in an effort to start a debian-cygwin project. dpkg does use autoconf, and as such, I ran it in it's default state. I will try re-running it with the pointers you gave me, and then see about what it takes to get it to build OOB. Thanks for you time, and patience in this case with a very abrupt and hasty plea for help. On Mon, 27 Aug 2001 14:14:26 -0400, 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 11:14 ` Charles Wilson 2001-08-27 13:51 ` Mark Paulus @ 2001-08-27 13:51 ` Mark Paulus 2001-12-18 21:33 ` Charles Wilson 2 siblings, 0 replies; 12+ messages in thread From: Mark Paulus @ 2001-08-27 13:51 UTC (permalink / raw) To: cygwin mailing list; +Cc: cygwin Ok, I am guilty as charged of the "minimilistic" information. I am trying to build the debian dpkg source package, in an effort to start a debian-cygwin project. dpkg does use autoconf, and as such, I ran it in it's default state. I will try re-running it with the pointers you gave me, and then see about what it takes to get it to build OOB. Thanks for you time, and patience in this case with a very abrupt and hasty plea for help. On Mon, 27 Aug 2001 14:14:26 -0400, 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: problem building program: undef ref _imp__gettext 2001-08-27 11:14 ` Charles Wilson 2001-08-27 13:51 ` Mark Paulus 2001-08-27 13:51 ` Mark Paulus @ 2001-12-18 21:33 ` Charles Wilson 2 siblings, 0 replies; 12+ messages in thread From: Charles Wilson @ 2001-12-18 21:33 UTC (permalink / raw) To: Charles Wilson; +Cc: Mark Paulus, cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* problem building program: undef ref _imp__gettext @ 2001-08-27 10:22 Mark Paulus 0 siblings, 0 replies; 12+ messages in thread From: Mark Paulus @ 2001-08-27 10:22 UTC (permalink / raw) To: cygwin Hi, I'm trying to compile/link a program, and I'm getting the following undefined reference: _imp__gettext. Is there some Environment variable, or something special I need to do to enable gettext?? (BTW, where is the '_imp_' getting pre-pended to the name anyway??) Thanks. -- 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] 12+ messages in thread
end of thread, other threads:[~2001-12-19 5:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200108271722.f7RHMiN20824@mail.ee.gatech.edu> 2001-08-27 10:42 ` problem building program: undef ref _imp__gettext Charles Wilson 2001-08-27 10:49 ` Mark Paulus [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] <200108271752.f7RHqGg23970@mail.ee.gatech.edu> 2001-08-27 11:14 ` Charles Wilson 2001-08-27 13:51 ` Mark Paulus 2001-08-27 13:51 ` Mark Paulus 2001-12-18 21:33 ` Charles Wilson 2001-08-27 10:22 Mark Paulus
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).