From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 19 Nov 2003 14:15:49 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 245 ************************************************** Tuesday 18 November 2003 Number 245 ************************************************** Subjects for today 1 Re: creating intl/Makefile : Henry Sobotka 2 Re: creating intl/Makefile : John Poltorak 3 Re: creating intl/Makefile : Henry Sobotka 4 Re: creating intl/Makefile : Henry Sobotka 5 Re: wxWindows : John Poltorak 6 Re: wxWindows : John Poltorak 7 Re: wxWindows : Stefan Neis 8 Re: wxWindows : Stefan Neis 9 Re: std::min? : Andrea Venturoli 10 wxWindows - checking for byacc... no : John Poltorak 11 Re: creating intl/Makefile : John Poltorak 12 Re: creating intl/Makefile : Henry Sobotka 13 Re: creating intl/Makefile : John Poltorak 14 Re: creating intl/Makefile : Henry Sobotka 15 Re: wxWindows - checking for byacc... no : John Poltorak 16 Re: creating intl/Makefile : John Poltorak 17 Re: creating intl/Makefile : John Poltorak 18 Re: wxWindows : Stefan Neis 19 Re: wxWindows : Stefan Neis 20 Re: std::min? : Stefan Neis 21 Re: wxWindows - checking for byacc... no : Stefan Neis 22 Re: wxWindows - checking for byacc... no : Stefan Neis 23 Re: creating intl/Makefile : Stefan Neis 24 Re: creating intl/Makefile : John Poltorak 25 Re: wxWindows - checking for byacc... no : Stefan Neis **= Email 1 ==========================** Date: Wed, 19 Nov 2003 09:40:23 -0500 From: Henry Sobotka Subject: Re: creating intl/Makefile John Poltorak wrote: > > On Tue, Nov 18, 2003 at 04:40:45PM -0800, Dave and Natalie wrote: > > On Mon, 17 Nov 2003 14:57:16 +0000, John Poltorak wrote: > > > > > > > >If the option --without-included-gettext is specified for configure, > > >should intl/Makefile be created? > > > > I'd think so, if only because the main makefile will call intl/Makefile. It just shouldn't do anything. Try running make all in intl > > ... so running Make in intl should say 'nothing to do'? > > What has gone wrong if it tries to build intl lib? Nothing. It's not unusual for a build system to create all the Makefiles for a project regardless of configure options. and use a DIRS variable or equivalent in a higher-level Makefile to control what gets built. In other words, something's wrong only if make enters intl and starts building when run from the top level. h~ **= Email 2 ==========================** Date: Wed, 19 Nov 2003 09:56:14 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Tue, Nov 18, 2003 at 04:40:45PM -0800, Dave and Natalie wrote: > On Mon, 17 Nov 2003 14:57:16 +0000, John Poltorak wrote: > > > > >If the option --without-included-gettext is specified for configure, > >should intl/Makefile be created? > > I'd think so, if only because the main makefile will call intl/Makefile. It just shouldn't do anything. Try running make all in intl ... so running Make in intl should say 'nothing to do'? What has gone wrong if it tries to build intl lib? > Dave -- John **= Email 3 ==========================** Date: Wed, 19 Nov 2003 10:33:18 -0500 From: Henry Sobotka Subject: Re: creating intl/Makefile John Poltorak wrote: > > The problem is that when I specify --without-included-gettext for an app > such as TEXINFO, configure has these checks:- > > checking whether included gettext is requested... no > checking for GNU gettext in libc... no > checking for GNU gettext in libintl... no > > To me this suggests that configure checks the external intl lib first and > decides it is not suitable so uses the internal one instead. > > If my understanding is correct then there must be a problem with the > external one. Or rather configure may simply not be finding it, e.g. if it expects libintl.a whereas you have intl.a. config.log should show details of the failure. h~ **= Email 4 ==========================** Date: Wed, 19 Nov 2003 12:14:23 -0500 From: Henry Sobotka Subject: Re: creating intl/Makefile John Poltorak wrote: > > configure:10401: checking for GNU gettext in libintl > configure:10434: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > e:\tmp\ccc12227: Undefined symbol _libintl_bindtextdomain referenced from text segment > e:\tmp\ccc12227: Undefined symbol _libintl_gettext referenced from text segment > > I guess I can use EMXEXP on my intl lib to check whether those symbols > exist... If they do, then it's a filename or path problem, if they don't > then it's library build which is wrong... > > Or could it be somethong else? It's definitely finding intl.a because otherwise you would get a no-such-file error message from ld. Check your intl.a to see what it does export. h~ **= Email 5 ==========================** Date: Wed, 19 Nov 2003 12:32:23 +0000 From: John Poltorak Subject: Re: wxWindows On Wed, Nov 19, 2003 at 01:22:28PM +0100, Stefan Neis wrote: > On Tue, 18 Nov 2003, John Poltorak wrote: > > > I have just downloaded wxBase-2.4.2 and wxOS2-2.4.2 for comparison and > > wonder whether I would be able to use the former to build wxWindows... > > They have the same configure.in and Makefile.in. > > Well, wxBase is just the collection of the non-GUI related classes > (so you have e.g. cross-platform socket support, cross-platform threading > support and cross platform file support). However, I suppose you're > interested mostly in the GUI part, sp wxBase won't be that helpful). > > Configure.in and Makefile.in should be the same, however the generated > Makefiles should be slightly different... > Also, the configure scripts are supposed to be different, wxBase contains > the Unix-generated configure script, whereas wxOS2 should contain an OS/2 > specific version of "configure". Yes, I see that, but if I was using UX2BS then I should be able to grab wxBase and create an OS/2 specific configure for myself. Yes? The archive is considerably smaller. > BTW, is there an OS/2 version of Borland's "TVision" library? Somebody is > working on a TVision-Port of wxWindows which means we could get a > text-mode GUI for free if such a beast exists for OS/2. Is this any use:- ? http://tvision.sourceforge.net/ > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 6 ==========================** Date: Wed, 19 Nov 2003 12:37:47 +0000 From: John Poltorak Subject: Re: wxWindows On Wed, Nov 19, 2003 at 01:15:12PM +0100, Stefan Neis wrote: > On Tue, 18 Nov 2003, John Poltorak wrote: > > > > > Abnormal program termination > > > > > > > > checking whether we are using the GNU C compiler... no > > > > checking whether gcc accepts -g... no > > > > checking for gcc option to accept ANSI C... none needed > > > > > > and as a result of the configure run, I get complete nonsense. > > > Any idea which tool is missing to make configure happy? I'm lost... > > > > Which version of autoconf produced configure? > > autoconf-2.57, OS/2 version... > It works on my other box and seems to have worked for some other people, > so it really must be some problem with what software I have (not!) > installed on that particular computer. You could install UX2BS ;-)... It only takes a minute or two for the basic system to install ;-)... > Regards > Stefan > -- John **= Email 7 ==========================** Date: Wed, 19 Nov 2003 13:15:12 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows On Tue, 18 Nov 2003, John Poltorak wrote: > > > Abnormal program termination > > > > > > checking whether we are using the GNU C compiler... no > > > checking whether gcc accepts -g... no > > > checking for gcc option to accept ANSI C... none needed > > > > and as a result of the configure run, I get complete nonsense. > > Any idea which tool is missing to make configure happy? I'm lost... > > Which version of autoconf produced configure? autoconf-2.57, OS/2 version... It works on my other box and seems to have worked for some other people, so it really must be some problem with what software I have (not!) installed on that particular computer. Regards Stefan **= Email 8 ==========================** Date: Wed, 19 Nov 2003 13:22:28 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows On Tue, 18 Nov 2003, John Poltorak wrote: > I have just downloaded wxBase-2.4.2 and wxOS2-2.4.2 for comparison and > wonder whether I would be able to use the former to build wxWindows... > They have the same configure.in and Makefile.in. Well, wxBase is just the collection of the non-GUI related classes (so you have e.g. cross-platform socket support, cross-platform threading support and cross platform file support). However, I suppose you're interested mostly in the GUI part, sp wxBase won't be that helpful). Configure.in and Makefile.in should be the same, however the generated Makefiles should be slightly different... Also, the configure scripts are supposed to be different, wxBase contains the Unix-generated configure script, whereas wxOS2 should contain an OS/2 specific version of "configure". BTW, is there an OS/2 version of Borland's "TVision" library? Somebody is working on a TVision-Port of wxWindows which means we could get a text-mode GUI for free if such a beast exists for OS/2. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 9 ==========================** Date: Wed, 19 Nov 2003 14:31:07 EST From: Andrea Venturoli Subject: Re: std::min? ** Reply to note from "Dave and Natalie" Tue, 18 Nov 2003 15:00:18 -0800 > Actually its not my code but the code for Blackbox, a window manager and the > code does compile on most *nixes. I wonder if size_t is different on *nix? > Perhaps just a subset of integer? I know, I have written a library that compiles correctly on linux, Windows and FreeBSD, but requires this cast on OS/2. I guess (but I didn't look it up) it's just a *de facto* standard that size_t is unsigned int, while on OS/2 it's not. bye av. **= Email 10 ==========================** Date: Wed, 19 Nov 2003 14:43:52 +0000 From: John Poltorak Subject: wxWindows - checking for byacc... no I'm going through my first attempt to build wxWindows and see s check for byacc failing. What does it actually look for? I have installed BYACC but is actually called yacc.exe. Is that the wrong name for it? -- John **= Email 11 ==========================** Date: Wed, 19 Nov 2003 15:00:06 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Wed, Nov 19, 2003 at 09:40:23AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > On Tue, Nov 18, 2003 at 04:40:45PM -0800, Dave and Natalie wrote: > > > On Mon, 17 Nov 2003 14:57:16 +0000, John Poltorak wrote: > > > > > > > > > > >If the option --without-included-gettext is specified for configure, > > > >should intl/Makefile be created? > > > > > > I'd think so, if only because the main makefile will call intl/Makefile. It just shouldn't do anything. Try running make all in intl > > > > ... so running Make in intl should say 'nothing to do'? > > > > What has gone wrong if it tries to build intl lib? > > Nothing. It's not unusual for a build system to create all the Makefiles > for a project regardless of configure options. and use a DIRS variable > or equivalent in a higher-level Makefile to control what gets built. In > other words, something's wrong only if make enters intl and starts > building when run from the top level. The problem is that when I specify --without-included-gettext for an app such as TEXINFO, configure has these checks:- checking whether included gettext is requested... no checking for GNU gettext in libc... no checking for GNU gettext in libintl... no To me this suggests that configure checks the external intl lib first and decides it is not suitable so uses the internal one instead. If my understanding is correct then there must be a problem with the external one. > h~ -- John **= Email 12 ==========================** Date: Wed, 19 Nov 2003 15:12:22 -0500 From: Henry Sobotka Subject: Re: creating intl/Makefile John Poltorak wrote: > > configure:10001: checking for GNU gettext in libintl > configure:10034: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > ld: No such file or directory for intl.a Then presumably it's not in LIBRARY_PATH. > EMXEXP doesn't see anything at all. Is that the right program to use? Your intl.a is probably an import library for intl.dll, in which case emxexp draws a blank. In that case the simplest thing to do is look at the .def file used to create the DLL. h~ **= Email 13 ==========================** Date: Wed, 19 Nov 2003 16:02:19 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Wed, Nov 19, 2003 at 10:33:18AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > The problem is that when I specify --without-included-gettext for an app > > such as TEXINFO, configure has these checks:- > > > > checking whether included gettext is requested... no > > checking for GNU gettext in libc... no > > checking for GNU gettext in libintl... no > > > > To me this suggests that configure checks the external intl lib first and > > decides it is not suitable so uses the internal one instead. > > > > If my understanding is correct then there must be a problem with the > > external one. > > Or rather configure may simply not be finding it, e.g. if it expects > libintl.a whereas you have intl.a. config.log should show details of the > failure. configure:9952: checking whether included gettext is requested configure:9962: result: no configure:9973: checking for GNU gettext in libc configure:9998: gcc -o conftest.exe -Dlstat=stat conftest.c >&5 e:\tmp\ccc12203: Undefined symbol _libintl_bindtextdomain referenced from text segment e:\tmp\ccc12203: Undefined symbol _libintl_gettext referenced from text segment e:\tmp\ccc12203: Undefined symbol __nl_msg_cat_cntr referenced from text segment e:\tmp\ccc12203: Undefined symbol __nl_domain_bindings referenced from text segment configure:10001: $? = 1 configure: failed program was: ..... configure:10018: result: no configure:10401: checking for GNU gettext in libintl configure:10434: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 e:\tmp\ccc12227: Undefined symbol _libintl_bindtextdomain referenced from text segment e:\tmp\ccc12227: Undefined symbol _libintl_gettext referenced from text segment configure:10437: $? = 1 configure: failed program was: ..... configure:10504: result: no configure:10551: checking whether to use NLS configure:10553: result: yes configure:10556: checking where the gettext function comes from configure:10567: result: included intl directory I guess I can use EMXEXP on my intl lib to check whether those symbols exist... If they do, then it's a filename or path problem, if they don't then it's library build which is wrong... Or could it be somethong else? > h~ > -- John **= Email 14 ==========================** Date: Wed, 19 Nov 2003 17:16:40 -0500 From: Henry Sobotka Subject: Re: creating intl/Makefile John Poltorak wrote: > [SNIP] > > "libintl_bindtextdomain" > "libintl_gettext" This missing symbols are obviously there. Try renaming intl.a and run emximp -o intl.a intl.def If the resulting intl.a is the same size as the original, then ld may be using another one elsewhere on your machine. If the sizes differ, the failure should go away with the new one. h~ **= Email 15 ==========================** Date: Wed, 19 Nov 2003 19:42:48 +0000 From: John Poltorak Subject: Re: wxWindows - checking for byacc... no On Wed, Nov 19, 2003 at 08:26:09PM +0100, Stefan Neis wrote: > On Wed, 19 Nov 2003, John Poltorak wrote: > > > I'm going through my first attempt to build wxWindows and see s check for > > byacc failing. > > > > What does it actually look for? I have installed BYACC but is actually > > called yacc.exe. Is that the wrong name for it? > > AC_CHECK_YACC is one of autoconf's built-in functions which checks for > executables named bison, byacc and yacc (in that order). So if you have > a yacc.exe, testing for bison and byacc will fail and testing for yacc > should find yacc.exe which should be just fine. But there is only a check for bison and byacc. I don't see an explicit check for yacc... What I have just added to config.site is:- YACC=yacc and now I get:- checking for bison... yacc Does this look OK? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 16 ==========================** Date: Wed, 19 Nov 2003 19:50:53 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Wed, Nov 19, 2003 at 12:14:23PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > configure:10401: checking for GNU gettext in libintl > > configure:10434: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > > e:\tmp\ccc12227: Undefined symbol _libintl_bindtextdomain referenced from text segment > > e:\tmp\ccc12227: Undefined symbol _libintl_gettext referenced from text segment > > > > I guess I can use EMXEXP on my intl lib to check whether those symbols > > exist... If they do, then it's a filename or path problem, if they don't > > then it's library build which is wrong... > > > > Or could it be somethong else? > > It's definitely finding intl.a because otherwise you would get a > no-such-file error message from ld. That's useful to know. I just checked to make sure:- configure:10001: checking for GNU gettext in libintl configure:10034: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 ld: No such file or directory for intl.a > Check your intl.a to see what it > does export. EMXEXP doesn't see anything at all. Is that the right program to use? > h~ > -- John **= Email 17 ==========================** Date: Wed, 19 Nov 2003 20:04:58 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Wed, Nov 19, 2003 at 08:33:08PM +0100, Stefan Neis wrote: > On Wed, 19 Nov 2003, John Poltorak wrote: > > > configure:10434: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > > e:\tmp\ccc12227: Undefined symbol _libintl_bindtextdomain referenced from text segment > > e:\tmp\ccc12227: Undefined symbol _libintl_gettext referenced from text segment > > > I guess I can use EMXEXP on my intl lib to check whether those symbols > > exist... > > Actually, I'd suggest to rather use "nm intl.a | grep " T " " (nm lists > all the symbols referenced by the library and grep " T " extracts those > that actually are (globally) defined by the lib. The advantage is that > you get them in exactly the same way that gcc is using in it's error > message, while emxexp (IIRC) might add or remove an extra underscore (?). None occur when I search for " T ". I do get this though:- C:\emx\bin>nm p:intl.a | grep "0 e" 00000000 e _gettext 00000000 e _dgettext 00000000 e _dcgettext 00000000 e _ngettext 00000000 e _dngettext 00000000 e _dcngettext 00000000 e _textdomain 00000000 e _bindtextdomain 00000000 e _bind_textdomain_codeset 00000000 e _libintl_bindtextdomain 00000000 e _libintl_bind_textdomain_codeset 00000000 e _libintl_dcgettext 00000000 e _libintl_dgettext 00000000 e _libintl_gettext 00000000 e __nl_find_domain 00000000 e __nl_init_domain_conv 00000000 e __nl_free_domain_conv 00000000 e __nl_load_domain 00000000 e __nl_expand_alias 00000000 e _libintl_textdomain 00000000 e __nl_make_l10nflist 00000000 e __nl_normalize_codeset 00000000 e __nl_find_language 00000000 e __nl_explode_name 00000000 e _libintl_nl_default_default_domain 00000000 e _libintl_nl_current_default_domain 00000000 e _libintl_dcigettext 00000000 e __nl_find_msg 00000000 e _libintl_dcngettext 00000000 e _libintl_dngettext 00000000 e _libintl_ngettext 00000000 e _libintl_gettext_free_exp 00000000 e _libintl_gettextparse 00000000 e _libintl_gettext_germanic_plural 00000000 e _libintl_gettext_extract_plural 00000000 e _locale_charset 00000000 e __nl_locale_name 00000000 e __nl_getenv 00000000 e __nlos2_libdir 00000000 e __nlos2_localealiaspath 00000000 e __nlos2_localedir It seems to me that something is missing... > Regards, > Stefan > > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 18 ==========================** Date: Wed, 19 Nov 2003 20:11:55 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows On Wed, 19 Nov 2003, John Poltorak wrote: > Yes, I see that, but if I was using UX2BS then I should be able to grab > wxBase and create an OS/2 specific configure for myself. Yes? Yes. However, you also need to run autoconf in the samples, demos, contrib and utils subdirectories since those configure scripts are automatically called by the main one ... > Is this any use:- ? > > http://tvision.sourceforge.net/ Probably yes, thanks. Will have a look ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 19 ==========================** Date: Wed, 19 Nov 2003 20:13:11 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows On Wed, 19 Nov 2003, John Poltorak wrote: > You could install UX2BS ;-)... Unless I'm behind some ugly firewall, right? And this is the case for this particular environment ... :-( Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 20 ==========================** Date: Wed, 19 Nov 2003 20:18:57 +0100 (CET) From: Stefan Neis Subject: Re: std::min? On Wed, 19 Nov 2003, Andrea Venturoli wrote: > I guess (but I didn't look it up) it's just a *de facto* standard that > size_t is unsigned int, while on OS/2 it's not. I suppose it will be unsigned long (just as for OS/2) on all 64-bit systems. But still, I don't quite see how template instantiation will work if one type is size_t and the other one is unsigned int, even if it knows the only difference is a typedef. I start to suppose that newer gcc versions know some more details for integral types and automatically can cast one of two arguments to find a matching template... Regards, Stefan. -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 21 ==========================** Date: Wed, 19 Nov 2003 20:26:09 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows - checking for byacc... no On Wed, 19 Nov 2003, John Poltorak wrote: > I'm going through my first attempt to build wxWindows and see s check for > byacc failing. > > What does it actually look for? I have installed BYACC but is actually > called yacc.exe. Is that the wrong name for it? AC_CHECK_YACC is one of autoconf's built-in functions which checks for executables named bison, byacc and yacc (in that order). So if you have a yacc.exe, testing for bison and byacc will fail and testing for yacc should find yacc.exe which should be just fine. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 22 ==========================** Date: Wed, 19 Nov 2003 20:26:09 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows - checking for byacc... no On Wed, 19 Nov 2003, John Poltorak wrote: > I'm going through my first attempt to build wxWindows and see s check for > byacc failing. > > What does it actually look for? I have installed BYACC but is actually > called yacc.exe. Is that the wrong name for it? AC_CHECK_YACC is one of autoconf's built-in functions which checks for executables named bison, byacc and yacc (in that order). So if you have a yacc.exe, testing for bison and byacc will fail and testing for yacc should find yacc.exe which should be just fine. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 23 ==========================** Date: Wed, 19 Nov 2003 20:33:08 +0100 (CET) From: Stefan Neis Subject: Re: creating intl/Makefile On Wed, 19 Nov 2003, John Poltorak wrote: > configure:10434: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > e:\tmp\ccc12227: Undefined symbol _libintl_bindtextdomain referenced from text segment > e:\tmp\ccc12227: Undefined symbol _libintl_gettext referenced from text segment > I guess I can use EMXEXP on my intl lib to check whether those symbols > exist... Actually, I'd suggest to rather use "nm intl.a | grep " T " " (nm lists all the symbols referenced by the library and grep " T " extracts those that actually are (globally) defined by the lib. The advantage is that you get them in exactly the same way that gcc is using in it's error message, while emxexp (IIRC) might add or remove an extra underscore (?). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 24 ==========================** Date: Wed, 19 Nov 2003 20:35:51 +0000 From: John Poltorak Subject: Re: creating intl/Makefile On Wed, Nov 19, 2003 at 03:12:22PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > configure:10001: checking for GNU gettext in libintl > > configure:10034: gcc -o conftest.exe -Dlstat=stat conftest.c -lintl >&5 > > ld: No such file or directory for intl.a > > Then presumably it's not in LIBRARY_PATH. I just renamed it temporarily for the purpose of the test. > > EMXEXP doesn't see anything at all. Is that the right program to use? > > Your intl.a is probably an import library for intl.dll, in which case > emxexp draws a blank. In that case the simplest thing to do is look at > the .def file used to create the DLL. Here are the first few lines of the intl.def:- LIBRARY intl INITINSTANCE DESCRIPTION "intl" DATA SINGLE NONSHARED EXPORTS ; From intl-compat.lo "gettext" "dgettext" "dcgettext" "ngettext" "dngettext" "dcngettext" "textdomain" "bindtextdomain" "bind_textdomain_codeset" ; From bindtextdom.lo "libintl_bindtextdomain" "libintl_bind_textdomain_codeset" ; From dcgettext.lo "libintl_dcgettext" ; From dgettext.lo "libintl_dgettext" ; From gettext.lo "libintl_gettext" Does that look OK and what do I do with it? > > h~ > -- John **= Email 25 ==========================** Date: Wed, 19 Nov 2003 21:31:42 +0100 (CET) From: Stefan Neis Subject: Re: wxWindows - checking for byacc... no On Wed, 19 Nov 2003, John Poltorak wrote: > But there is only a check for bison and byacc. I don't see an explicit > check for yacc... Seems like I might have misread AC_PROGRAM_YACC definition... > What I have just added to config.site is:- > > YACC=yacc > > and now I get:- > > > checking for bison... yacc > > > Does this look OK? I'll leave that for our autoconf expert to answer, now that you've proven my first answer to be wrong ... ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'.