Date: Sun, 4 Apr 2004 00:04:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 336 ************************************************** Saturday 03 April 2004 Number 336 ************************************************** Subjects for today 1 Re: Autoconf v2.59 : Knut St. Osmundsen" 2 Re: Building DLLs : Knut St. Osmundsen" 3 Re: Building DLLs : John Poltorak 4 Re: Autoconf v2.59 : John Poltorak 5 Re: Autoconf v2.59 : Andreas Buening 6 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : Andreas Buening 7 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : John Poltorak 8 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : Andreas Buening 9 Converting CRLF to LF : John Poltorak 10 Re: Converting CRLF to LF : Thomas Dickey 11 Re: Converting CRLF to LF : Yuri Dario" 12 Re: Autoconf v2.59 : John Poltorak 13 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : Dave and Natalie" 14 Re: Converting CRLF to LF : John Poltorak 15 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : John Poltorak 16 Re: Converting CRLF to LF : Masaru Nomiya 17 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : John Poltorak 18 Re: Autoconf v2.59 : Andreas Buening 19 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : Andreas Buening 20 Re: Converting CRLF to LF : Stefan Neis 21 Re: Converting CRLF to LF : John Poltorak 22 Re: Autoconf v2.59 : John Poltorak 23 Re: Converting CRLF to LF : Stefan Neis 24 Re: cannot export symbol _nl_msg_cat_cntr of type 9 : John Poltorak 25 Re: Converting CRLF to LF : John Poltorak **= Email 1 ==========================** Date: Fri, 02 Apr 2004 16:38:29 +0200 From: "Knut St. Osmundsen" Subject: Re: Autoconf v2.59 John Poltorak wrote: > > Does anyone know if Autoconf v2.59 works straight out of the box on > OS/2? > > Does Innotek's version have any modifications to the distributed > source? > Yes, I did some changes. `cvs diff -r AUTOCONF_2-59` generates a 12kb diff file here. Kind Regards, knut **= Email 2 ==========================** Date: Fri, 02 Apr 2004 16:33:32 +0200 From: "Knut St. Osmundsen" Subject: Re: Building DLLs Dave and Natalie wrote: > On Thu, 01 Apr 2004 17:20:47 +0200, Knut St. Osmundsen wrote: > > >> There is no flag for building both a.out and omf binaries, that >> doesn't make much sense IMHO. > > > Well when building common DLLs such as zlib for distributation it is > nice to include both a.out and omf export libs (and static) so anyone > using it has a choice That I strongly agree with. But that just means you have to do two emxomf operations: emxomf -o libz_dll.a z.def && emxomf -o libz_dll.lib z.def Kind Regards, knut **= Email 3 ==========================** Date: Fri, 2 Apr 2004 15:58:42 +0000 From: John Poltorak Subject: Re: Building DLLs On Fri, Apr 02, 2004 at 04:33:32PM +0200, Knut St. Osmundsen wrote: > Dave and Natalie wrote: > > On Thu, 01 Apr 2004 17:20:47 +0200, Knut St. Osmundsen wrote: > > > > > >> There is no flag for building both a.out and omf binaries, that > >> doesn't make much sense IMHO. > > > > > > Well when building common DLLs such as zlib for distributation it is > > nice to include both a.out and omf export libs (and static) so anyone > > using it has a choice > > That I strongly agree with. But that just means you have to do two > emxomf operations: emxomf -o libz_dll.a z.def && emxomf -o libz_dll.lib > z.def Can't issues like this be dealt with automatically by changes to libtool? > Kind Regards, > knut -- John **= Email 4 ==========================** Date: Fri, 2 Apr 2004 16:57:17 +0000 From: John Poltorak Subject: Re: Autoconf v2.59 On Fri, Apr 02, 2004 at 04:38:29PM +0200, Knut St. Osmundsen wrote: > John Poltorak wrote: > > > > Does anyone know if Autoconf v2.59 works straight out of the box on > > OS/2? > > > > Does Innotek's version have any modifications to the distributed > > source? > > > > Yes, I did some changes. `cvs diff -r AUTOCONF_2-59` generates a 12kb > diff file here. That sounds like quite a lot of changes. Do you think any of them should be submitted to the Autoconf developers for possible inclusions with forthcoming versions of Autoconf? > Kind Regards, > knut -- John **= Email 5 ==========================** Date: Fri, 02 Apr 2004 21:07:25 +0100 From: Andreas Buening Subject: Re: Autoconf v2.59 Knut St. Osmundsen wrote: > Yes, I did some changes. `cvs diff -r AUTOCONF_2-59` generates a 12kb > diff file here. Could you give us a hint which kind of changes you did, please? Bye, Andreas **= Email 6 ==========================** Date: Fri, 02 Apr 2004 21:07:05 +0100 From: Andreas Buening Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 John Poltorak wrote: > > In trying to rebuild the port of gettext 0.10.39 I get this error msg:- > gcc -Zdll -O2 -s -Zmt -D__ST_MT_ERRNO__ -o .libs/intl.dll intl-compat.lo bindtextdom.lo dcgettext.lo dgettext.lo gettext.lo finddomain.lo loadmsgcat.lo localealias.lo textdomain.lo l10nflist.lo explodename.lo dcigettext.lo dcngettext.lo dngettext.lo ngettext.lo plural.lo localcharset.lo .libs/intl.def > emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > C:\UNIXOS2\EMX\BIN\ld.exe: emxbind failed > > Does this look familiar to anyone? I vaguely remember. Maybe you're using an unpatched libtool. Bye, Andreas **= Email 7 ==========================** Date: Fri, 2 Apr 2004 20:17:59 +0000 From: John Poltorak Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 On Fri, Apr 02, 2004 at 09:07:05PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > In trying to rebuild the port of gettext 0.10.39 I get this error msg:- > > > gcc -Zdll -O2 -s -Zmt -D__ST_MT_ERRNO__ -o .libs/intl.dll intl-compat.lo bindtextdom.lo dcgettext.lo dgettext.lo gettext.lo finddomain.lo loadmsgcat.lo localealias.lo textdomain.lo l10nflist.lo explodename.lo dcigettext.lo dcngettext.lo dngettext.lo ngettext.lo plural.lo localcharset.lo .libs/intl.def > > emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > > C:\UNIXOS2\EMX\BIN\ld.exe: emxbind failed > > > > Does this look familiar to anyone? > > I vaguely remember. I looked through my archive but never managed to resolve this the last time I tried. > Maybe you're using an unpatched libtool. I'm not using libtool at all. Should I be doing so? > > Bye, > Andreas -- John **= Email 8 ==========================** Date: Fri, 02 Apr 2004 21:29:55 +0100 From: Andreas Buening Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 John Poltorak wrote: > > On Fri, Apr 02, 2004 at 09:07:05PM +0100, Andreas Buening wrote: [snip] > > I vaguely remember. > > I looked through my archive but never managed to resolve this the last > time I tried. > > > Maybe you're using an unpatched libtool. > > I'm not using libtool at all. Should I be doing so? There is an included libtool but neither do I know what exactly you did nor do I exactly remember what was the status of 0.10.39. Sorry, but it was too long ago. Bye, Andreas **= Email 9 ==========================** Date: Fri, 2 Apr 2004 21:31:58 +0000 From: John Poltorak Subject: Converting CRLF to LF Is there any way to convert all the text files in a ZIP archive from CRLF to LF on extraction? I have 170 files within several directories that I would like to convert. Is there a simple way to do this? -- John **= Email 10 ==========================** Date: Fri, 2 Apr 2004 15:51:59 -0500 (EST) From: Thomas Dickey Subject: Re: Converting CRLF to LF On Fri, 2 Apr 2004, John Poltorak wrote: > > Is there any way to convert all the text files in a ZIP archive from CRLF > to LF on extraction? > > > I have 170 files within several directories that I would like to convert. > > > Is there a simple way to do this? perhaps unzip -a -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 11 ==========================** Date: Fri, 02 Apr 2004 23:20:40 +0200 (CDT) From: "Yuri Dario" Subject: Re: Converting CRLF to LF >Is there any way to convert all the text files in a ZIP archive from CRLF >to LF on extraction? unzip all files, zip again using -ll, unzip new archive. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 12 ==========================** Date: Fri, 2 Apr 2004 23:13:35 +0000 From: John Poltorak Subject: Re: Autoconf v2.59 On Fri, Apr 02, 2004 at 09:07:25PM +0100, Andreas Buening wrote: > Knut St. Osmundsen wrote: > > > Yes, I did some changes. `cvs diff -r AUTOCONF_2-59` generates a 12kb > > diff file here. > > Could you give us a hint which kind of changes you did, please? Having just done a comparison there doesn't anything like that amount of changes, most of which are the addition of a drive letter to paths so wouldn't affect the operation of autoconf if it was being used on the same drive as the rest of the build system. There are also a number of changes of /bin/sh to sh which wouldn't matter if you do have \bin\sh.exe on the relavant drive. > > Bye, > Andreas -- John **= Email 13 ==========================** Date: Fri, 02 Apr 2004 20:36:06 -0800 From: "Dave and Natalie" Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 On Fri, 02 Apr 2004 21:07:05 +0100, Andreas Buening wrote: >John Poltorak wrote: >> >> In trying to rebuild the port of gettext 0.10.39 I get this error msg:- > >> gcc -Zdll -O2 -s -Zmt -D__ST_MT_ERRNO__ -o .libs/intl.dll intl-compat.lo bindtextdom.lo dcgettext.lo dgettext.lo gettext.lo finddomain.lo loadmsgcat.lo localealias.lo textdomain.lo l10nflist.lo explodename.lo dcigettext.lo dcngettext.lo dngettext.lo ngettext.lo plural.lo localcharset.lo .libs/intl.def >> emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 >> C:\UNIXOS2\EMX\BIN\ld.exe: emxbind failed >> >> Does this look familiar to anyone? > >I vaguely remember. Maybe you're using an unpatched libtool. Actually I vaguely remember this error too. Seems it came and went, perhaps depending on uptime and free resources or perhaps killing emxload fixed it, can't really remember. It may of been shell related too. I remember having to patch the DEF file too sometimes depending on shell, mostly by adding quotation marks. The big problem I have with intll.dll is linking to different libiconvs. I have gnu libiconv and also the one that comes with the newer GCCs including Innoteks. Actually I notice that Innoteks appear to be static libraries. I'm being more and more inclined to use static libraries more often. Dave **= Email 14 ==========================** Date: Sat, 3 Apr 2004 09:13:22 +0000 From: John Poltorak Subject: Re: Converting CRLF to LF On Fri, Apr 02, 2004 at 11:20:40PM +0200, Yuri Dario wrote: > >Is there any way to convert all the text files in a ZIP archive from CRLF > >to LF on extraction? > > unzip all files, zip again using -ll, unzip new archive. That's a very neat way of doing it. Thanks for the suggestion. > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.os2power.com/yuri > * http://www.teamos2.it > */ -- John **= Email 15 ==========================** Date: Sat, 3 Apr 2004 09:43:22 +0000 From: John Poltorak Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 On Fri, Apr 02, 2004 at 08:36:06PM -0800, Dave and Natalie wrote: > On Fri, 02 Apr 2004 21:07:05 +0100, Andreas Buening wrote: > > >John Poltorak wrote: > >> > >> In trying to rebuild the port of gettext 0.10.39 I get this error msg:- > > > >> gcc -Zdll -O2 -s -Zmt -D__ST_MT_ERRNO__ -o .libs/intl.dll intl-compat.lo bindtextdom.lo dcgettext.lo dgettext.lo gettext.lo finddomain.lo loadmsgcat.lo localealias.lo textdomain.lo l10nflist.lo explodename.lo dcigettext.lo dcngettext.lo dngettext.lo ngettext.lo plural.lo localcharset.lo .libs/intl.def > >> emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > >> C:\UNIXOS2\EMX\BIN\ld.exe: emxbind failed > >> > >> Does this look familiar to anyone? > > > >I vaguely remember. Maybe you're using an unpatched libtool. > > Actually I vaguely remember this error too. Seems it came and went, perhaps depending on uptime and free resources or perhaps killing emxload fixed it, can't really remember. I don't really like having errors which simply disappear for no apparent reason. Any idea what the error msg actually means? Does it suggest a problem with the compiled object, or is EMXBIND the problem? Where is the symbol being exported from? > It may of been shell related too. I remember having to patch the DEF > file too sometimes depending on shell, mostly by adding quotation marks. "nl_msg_cat_cntr" does appear in intl\.libs\intl.def, complete with quotes under the section:- ; From loadmsgcat.lo In this file the string appears right at the end of the file. I wonder if that is significant. BTW, what is a *.lo file ? > The big problem I have with intll.dll is linking to different libiconvs. I have gnu libiconv and also the one that comes with the newer GCCs including Innoteks. Actually I notice that Innoteks appear to be static libraries. I'm being more and more inclined to use static libraries more often. I'm finding the creation of INTL.DLL to be a major stumbling block and wish I could resolve it. I remember being able to build it correctly at one time, but there seemed to be so many hoops involved. > Dave -- John **= Email 16 ==========================** Date: Sat, 03 Apr 2004 17:55:12 +0900 From: Masaru Nomiya Subject: Re: Converting CRLF to LF Hello, In the Message; Subject : Converting CRLF to LF Message-ID : <20040402213158.N44505 at warpix.org> Date & Time: Fri, 2 Apr 2004 21:31:58 +0000 [John] == John Poltorak has written: John> Is there any way to convert all the text files in a ZIP archive from CRLF John> to LF on extraction? John> I have 170 files within several directories that I would like to convert. You have got a tool in the Emacs 20.7. That is, delcr.exe. [Somewhere]delcr -e * This convert all the text file from CRLF to LF. Hope this helps you,. --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "Bill! You married with Computers. Not with Me!" "No..., with money." **= Email 17 ==========================** Date: Sat, 3 Apr 2004 12:06:25 +0000 From: John Poltorak Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 On Sat, Apr 03, 2004 at 09:43:22AM +0000, John Poltorak wrote: > On Fri, Apr 02, 2004 at 08:36:06PM -0800, Dave and Natalie wrote: > > On Fri, 02 Apr 2004 21:07:05 +0100, Andreas Buening wrote: > > > > >John Poltorak wrote: > > >> > > >> In trying to rebuild the port of gettext 0.10.39 I get this error msg:- > > > > > >> gcc -Zdll -O2 -s -Zmt -D__ST_MT_ERRNO__ -o .libs/intl.dll intl-compat.lo bindtextdom.lo dcgettext.lo dgettext.lo gettext.lo finddomain.lo loadmsgcat.lo localealias.lo textdomain.lo l10nflist.lo explodename.lo dcigettext.lo dcngettext.lo dngettext.lo ngettext.lo plural.lo localcharset.lo .libs/intl.def > > >> emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > > >> C:\UNIXOS2\EMX\BIN\ld.exe: emxbind failed > > >> > > >> Does this look familiar to anyone? > > > > > >I vaguely remember. Maybe you're using an unpatched libtool. > > > > Actually I vaguely remember this error too. Seems it came and went, perhaps depending on uptime and free resources or perhaps killing emxload fixed it, can't really remember. > > I don't really like having errors which simply disappear for no apparent > reason. > > Any idea what the error msg actually means? Does it suggest a problem with > the compiled object, or is EMXBIND the problem? After trying EMXBIND from gcc 3.0.3 this error disappears and INTL.DLL appears to get created. It is somewhat on the large side though 160k... Previous versions have been 11k. Why would it be so much bigger? -- John **= Email 18 ==========================** Date: Sat, 03 Apr 2004 13:30:05 +0100 From: Andreas Buening Subject: Re: Autoconf v2.59 John Poltorak wrote: > > On Fri, Apr 02, 2004 at 09:07:25PM +0100, Andreas Buening wrote: > > Could you give us a hint which kind of changes you did, please? > > Having just done a comparison there doesn't anything like that amount of > changes, most of which are the addition of a drive letter to paths so > wouldn't affect the operation of autoconf if it was being used on the same > drive as the rest of the build system. There are also a number of changes > of /bin/sh to sh which wouldn't matter if you do have \bin\sh.exe on the > relavant drive. Hmm. Nevertheless, I'd like to know what's the new features and whether this is supposed to be incorporated into the main source. Having two different autoconf releases might be not the best idea. Bye, Andreas **= Email 19 ==========================** Date: Sat, 03 Apr 2004 13:29:59 +0100 From: Andreas Buening Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 John Poltorak wrote: > > On Fri, Apr 02, 2004 at 08:36:06PM -0800, Dave and Natalie wrote: > > Actually I vaguely remember this error too. Seems it came and went, perhaps depending on uptime and free resources or perhaps killing emxload fixed it, can't really remember. > > I don't really like having errors which simply disappear for no apparent > reason. > > Any idea what the error msg actually means? Does it suggest a problem with > the compiled object, or is EMXBIND the problem? Where is the symbol being > exported from? IIRC it means that the .def file is created by "emxexp" but not "emxexp -u". Therefore, the unitinialized global variable _nl_msg_cat_cntr is not put into the .def file also available in the dll. > In this file the string appears right at the end of the file. I wonder if > that is significant. > > BTW, what is a *.lo file ? A _L_ibtool _O_bject file. It's just a normal .o and it's being renamed to distinguish between "shared" and "static" object files. > > The big problem I have with intll.dll is linking to different libiconvs. I have gnu libiconv and also the one that comes with the newer GCCs including Innoteks. Actually I notice that Innoteks appear to be static libraries. I'm being more and more inclined to use static libraries more often. > > I'm finding the creation of INTL.DLL to be a major stumbling block and > wish I could resolve it. I remember being able to build it correctly at > one time, but there seemed to be so many hoops involved. Indeed, you have to do a lot of baby sitting if libtool is involved, and especially for intl. Sometimes you have to look carefully at the configure and make output to see what went wrong. :-( Bye, Andreas **= Email 20 ==========================** Date: Sat, 3 Apr 2004 14:34:44 +0200 (CEST) From: Stefan Neis Subject: Re: Converting CRLF to LF On Fri, 2 Apr 2004, Thomas Dickey wrote: > On Fri, 2 Apr 2004, John Poltorak wrote: > > > > > Is there any way to convert all the text files in a ZIP archive from CRLF > > to LF on extraction? > > > > > > I have 170 files within several directories that I would like to convert. > > > > > > Is there a simple way to do this? > > perhaps unzip -a On OS/2, that's rather going to do the conversion the other way round. BTW, John, why would you want to do that? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 21 ==========================** Date: Sat, 3 Apr 2004 13:47:57 +0000 From: John Poltorak Subject: Re: Converting CRLF to LF On Sat, Apr 03, 2004 at 02:34:44PM +0200, Stefan Neis wrote: > On Fri, 2 Apr 2004, Thomas Dickey wrote: > > > On Fri, 2 Apr 2004, John Poltorak wrote: > > > > > > > > Is there any way to convert all the text files in a ZIP archive from CRLF > > > to LF on extraction? > > > > > > > > > I have 170 files within several directories that I would like to convert. > > > > > > > > > Is there a simple way to do this? > > > > perhaps unzip -a > > On OS/2, that's rather going to do the conversion the other way round. > BTW, John, why would you want to do that? I wanted to do a quick comparison between GNU's Autoconf and Innotek's Autoconf to get an idea of the differences. Since they had different line termination, file size was not a good indicator. > > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. -- John **= Email 22 ==========================** Date: Sat, 3 Apr 2004 13:53:12 +0000 From: John Poltorak Subject: Re: Autoconf v2.59 --BZYFGq9+rHBLhTIf Content-Type: text/plain; charset=us-ascii On Sat, Apr 03, 2004 at 01:30:05PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Fri, Apr 02, 2004 at 09:07:25PM +0100, Andreas Buening wrote: > > > > Could you give us a hint which kind of changes you did, please? > > > > Having just done a comparison there doesn't anything like that amount of > > changes, most of which are the addition of a drive letter to paths so > > wouldn't affect the operation of autoconf if it was being used on the same > > drive as the rest of the build system. There are also a number of changes > > of /bin/sh to sh which wouldn't matter if you do have \bin\sh.exe on the > > relavant drive. > > Hmm. Nevertheless, I'd like to know what's the new features and whether > this is supposed to be incorporated into the main source. Having two > different autoconf releases might be not the best idea. Yes, it gets messy when there are different versions around. After removing the changes due to /bin/sh and $UNIXROOT I came up with the attached diff.. > > Bye, > Andreas -- John --BZYFGq9+rHBLhTIf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="P:\\unixos2\\workdir\\autoconf.diff" diff -ur autoconf-2.59/bin/autom4te.in autoconf-2.59-new/bin/autom4te.in --- autoconf-2.59/bin/autom4te.in Tue Oct 28 08:48:36 2003 +++ autoconf-2.59-new/bin/autom4te.in Fri Dec 26 04:23:24 2003 at at -283,7 +283,16 at at { fatal "$file:$.: no current language" unless defined $lang; - push at {$language{$lang}}, at words; + my at words2; + foreach my $word ( at words) + { + if (substr($word, 0, 6) eq '$eval(') + { + $word = eval(substr(substr($word, 6), 0, -1)); + } + push at words2, $word; + } + push at {$language{$lang}}, at words2; } else { diff -ur autoconf-2.59/configure autoconf-2.59-new/configure --- autoconf-2.59/configure Thu Nov 6 09:33:28 2003 +++ autoconf-2.59-new/configure Sat Dec 27 01:53:50 2003 at at -1156,6 +1156,37 at at fi done +# Backslashes into forward slashes: +# The following OS/2 specific code is performed AFTER config.site +# has been loaded to allow users to change their environment there. +# This strange code is necessary to deal with handling of backslashes by ksh. + +if test "$ac_emxsupport" != "no" -a "$ac_emxsupport" != "NO"; then + ac_save_IFS="$IFS" + IFS="\\" + ac_TEMP_PATH= + for ac_dir in $PATH; do + IFS=$ac_save_IFS + if test -z "$ac_TEMP_PATH"; then + ac_TEMP_PATH="$ac_dir" + else + ac_TEMP_PATH="$ac_TEMP_PATH/$ac_dir" + fi + done + export PATH="$ac_TEMP_PATH" + unset ac_TEMP_PATH +fi + +# set ac_executable_extensions! +if test "$ac_executable_extensions" = ""; then + if ls.exe --version >/dev/null 2>/dev/null; then + { echo "$as_me:$LINENO: WARNING: ac_executable_extensions not set, assuming .exe" >&5 +echo "$as_me: WARNING: ac_executable_extensions not set, assuming .exe" >&2;} + ac_executable_extensions=".exe" + export ac_executable_extensions + fi +fi + if test -r "$cache_file"; then # Some versions of bash will fail to source /dev/null (special # files actually), so we avoid doing that. diff -ur autoconf-2.59/lib/autoconf/general.m4 autoconf-2.59-new/lib/autoconf/general.m4 --- autoconf-2.59/lib/autoconf/general.m4 Mon Oct 27 11:10:56 2003 +++ autoconf-2.59-new/lib/autoconf/general.m4 Fri Dec 26 02:31:54 2003 at at -1692,6 +1692,36 at at . "$ac_site_file" fi done + +# Backslashes into forward slashes: +# The following OS/2 specific code is performed AFTER config.site +# has been loaded to allow users to change their environment there. +# This strange code is necessary to deal with handling of backslashes by ksh. + +if test "$ac_emxsupport" != "no" -a "$ac_emxsupport" != "NO"; then + ac_save_IFS="$IFS" + IFS="\\" + ac_TEMP_PATH= + for ac_dir in $PATH; do + IFS=$ac_save_IFS + if test -z "$ac_TEMP_PATH"; then + ac_TEMP_PATH="$ac_dir" + else + ac_TEMP_PATH="$ac_TEMP_PATH/$ac_dir" + fi + done + export PATH="$ac_TEMP_PATH" + unset ac_TEMP_PATH +fi + +# set ac_executable_extensions! +if test "$ac_executable_extensions" = ""; then + if ls.exe --version >/dev/null 2>/dev/null; then + AC_WARN([ac_executable_extensions not set, assuming .exe]) + ac_executable_extensions=".exe" + export ac_executable_extensions + fi +fi ]) diff -ur autoconf-2.59/lib/autoconf/libs.m4 autoconf-2.59-new/lib/autoconf/libs.m4 --- autoconf-2.59/lib/autoconf/libs.m4 Thu May 22 13:05:12 2003 +++ autoconf-2.59-new/lib/autoconf/libs.m4 Fri Dec 26 02:31:54 2003 at at -118,12 +118,18 at at AS_LITERAL_IF([$1], [AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1_$2])], [AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1''_$2])])dnl +dnl special treatment for EMX (OS/2) because AC_CHECK_LIB fails if FUNCTION is already in libc +AC_CHECK_FUNC([$2]) AC_CACHE_CHECK([for $2 in -l$1], ac_Lib, [ac_check_lib_save_LIBS=$LIBS LIBS="-l$1 $5 $LIBS" -AC_LINK_IFELSE([AC_LANG_CALL([], [$2])], - [AS_VAR_SET(ac_Lib, yes)], - [AS_VAR_SET(ac_Lib, no)]) +if test "$ac_cv_func_$2" = yes; then + AS_VAR_SET(ac_Lib, no) +else + AC_LINK_IFELSE([AC_LANG_CALL([], [$2])], + [AS_VAR_SET(ac_Lib, yes)], + [AS_VAR_SET(ac_Lib, no)]) +fi LIBS=$ac_check_lib_save_LIBS]) AS_IF([test AS_VAR_GET(ac_Lib) = yes], [m4_default([$3], [AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_LIB$1)) diff -ur autoconf-2.59/lib/autotest/general.m4 autoconf-2.59-new/lib/autotest/general.m4 --- autoconf-2.59/lib/autotest/general.m4 Fri Sep 26 09:14:18 2003 +++ autoconf-2.59-new/lib/autotest/general.m4 Wed Jan 14 03:03:30 2004 at at -569,11 +569,19 at at cp /dev/null $at_devnull fi -# Use `diff -u' when possible. -if diff -u $at_devnull $at_devnull >/dev/null 2>&1; then - at_diff='diff -u' +# Use `diff -au' when possible. +if diff -au $at_devnull $at_devnull >/dev/null 2>&1; then + at_diff='diff -au' else - at_diff=diff + if diff -u $at_devnull $at_devnull >/dev/null 2>&1; then + at_diff='diff -u' + else + if diff -a $at_devnull $at_devnull >/dev/null 2>&1; then + at_diff='diff -a' + else + at_diff=diff + fi + fi fi Only in autoconf-2.59-new: port.gmk Only in autoconf-2.59-new: README.os2 diff -ur autoconf-2.59/tests/local.at autoconf-2.59-new/tests/local.at --- autoconf-2.59/tests/local.at Wed Aug 27 15:52:26 2003 +++ autoconf-2.59-new/tests/local.at Wed Jan 14 03:54:14 2004 at at -60,7 +60,7 at at m4_define([AT_CHECK_AUTOM4TE], [AT_CHECK([autom4te $1], [$2], [$3], m4_ifval([$4], [stderr])) m4_ifval([$4], -[AT_CHECK([[sed -e 's,^\([^:]*\): *\([0-9][0-9]*\): *[^:]*m4: ,m4: \1: \2: ,' \ +[AT_CHECK([[sed -e 's,^\([^:]*\): *\([0-9][0-9]*\): *[^ ]*m4: ,m4: \1: \2: ,' \ -e 's,^[^:]*m4: *\([^:]*\): *\([0-9][0-9]*\): ,m4: \1: \2: ,' \ -e 's/^autom4te: [^ ]*m4 /autom4te: m4 /' \ -e 's/^autom4te: [^ ]*m4.exe /autom4te: m4 /' \ --BZYFGq9+rHBLhTIf-- **= Email 23 ==========================** Date: Sat, 3 Apr 2004 15:04:06 +0200 (CEST) From: Stefan Neis Subject: Re: Converting CRLF to LF On Sat, 3 Apr 2004, John Poltorak wrote: > I wanted to do a quick comparison between GNU's Autoconf and Innotek's > Autoconf to get an idea of the differences. Since they had different line > termination, file size was not a good indicator. I find "diff -w" most helpful in such cases ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 24 ==========================** Date: Sat, 3 Apr 2004 14:02:40 +0000 From: John Poltorak Subject: Re: cannot export symbol _nl_msg_cat_cntr of type 9 On Sat, Apr 03, 2004 at 01:29:59PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Fri, Apr 02, 2004 at 08:36:06PM -0800, Dave and Natalie wrote: > > > > Actually I vaguely remember this error too. Seems it came and went, perhaps depending on uptime and free resources or perhaps killing emxload fixed it, can't really remember. > > > > I don't really like having errors which simply disappear for no apparent > > reason. > > > > Any idea what the error msg actually means? Does it suggest a problem with > > the compiled object, or is EMXBIND the problem? Where is the symbol being > > exported from? > > IIRC it means that the .def file is created by "emxexp" but not > "emxexp -u". Therefore, the unitinialized global variable > _nl_msg_cat_cntr is not put into the .def file also available in > the dll. I checked the def and the variable was there, then subsequently tried a different version of emxbind and this problem disappeared, so I can only think that it must be a bug in the emxbind in gcc 2.8.1... > > > The big problem I have with intll.dll is linking to different libiconvs. I have gnu libiconv and also the one that comes with the newer GCCs including Innoteks. Actually I notice that Innoteks appear to be static libraries. I'm being more and more inclined to use static libraries more often. > > > > I'm finding the creation of INTL.DLL to be a major stumbling block and > > wish I could resolve it. I remember being able to build it correctly at > > one time, but there seemed to be so many hoops involved. > > Indeed, you have to do a lot of baby sitting if libtool is involved, > and especially for intl. Sometimes you have to look carefully > at the configure and make output to see what went wrong. :-( Gettext produces so much output that it is very difficult to see what is going wrong unless you know exactly what to expect. I don't, which makes it even more difficult. > Bye, > Andreas -- John **= Email 25 ==========================** Date: Sat, 3 Apr 2004 14:07:53 +0000 From: John Poltorak Subject: Re: Converting CRLF to LF On Sat, Apr 03, 2004 at 03:04:06PM +0200, Stefan Neis wrote: > On Sat, 3 Apr 2004, John Poltorak wrote: > > > I wanted to do a quick comparison between GNU's Autoconf and Innotek's > > Autoconf to get an idea of the differences. Since they had different line > > termination, file size was not a good indicator. > > I find "diff -w" most helpful in such cases ... I was using Ctrl-K in File Commander... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John