From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 20 Oct 2002 04:39:27 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 349 ************************************************** Saturday 19 October 2002 Number 349 ************************************************** Subjects for today 1 gettext 0.11.5 : Andreas Buening 2 Re: problems with zlib114 : Franz Bakan" 3 Re: gettext 0.11.5 : John Poltorak 4 Re: gettext 0.11.5 : Andreas Buening 5 Re: problems with zlib114 : Andreas Buening 6 Re: gettext 0.11.5 : Franz Bakan" 7 Re: gettext 0.11.5 : Andreas Buening 8 Re: gettext 0.11.5 : Franz Bakan" **= Email 1 ==========================** Date: Sun, 20 Oct 2002 00:24:20 +0200 From: Andreas Buening Subject: gettext 0.11.5 Hello! Some news: iconv/2 0.2.1: some bug fixes, iso-8859-15 added. gettext 0.11.5: http://unix.os2site.com/sw/binary/gettext/gettext-0_11_5-bin.zip The precompiled version (some executables, to be exactly) relies on libunixos2 0.1.1 (and iconv2/2 0.2.1 which is linked statically). 0.11.5 is forward and backward compatible to 0.10.35 and 0.10.39. Note: If you have problems with gettext there is a special debug dll version (gettext-0_11_5-bin-debug.zip) that prints some info to stderr. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 2 ==========================** Date: Sun, 20 Oct 2002 00:41:25 +0200 (CEST) From: "Franz Bakan" Subject: Re: problems with zlib114 On Sat, 19 Oct 2002 23:30:13 +0200, Andreas Buening wrote: >> z.dll from zlib114.zip is not backwards-compatible to >> the 113-version. [snip] >Eh, do you want to say that both dlls have different names? No, both contain (besides doc, diff, z.a, z.lib) a z.dll Franz **= Email 3 ==========================** Date: Sun, 20 Oct 2002 12:34:12 +0100 From: John Poltorak Subject: Re: gettext 0.11.5 On Sun, Oct 20, 2002 at 12:24:20AM +0200, Andreas Buening wrote: > Hello! > > Some news: > > iconv/2 0.2.1: some bug fixes, iso-8859-15 added. > > > gettext 0.11.5: > http://unix.os2site.com/sw/binary/gettext/gettext-0_11_5-bin.zip > > The precompiled version (some executables, to be exactly) relies on > libunixos2 0.1.1 (and iconv2/2 0.2.1 which is linked statically). > 0.11.5 is forward and backward compatible to 0.10.35 and 0.10.39. > Note: If you have problems with gettext there is a special > debug dll version (gettext-0_11_5-bin-debug.zip) > that prints some info to stderr. Is the source also available? I've been waiting a long time to find an easily buildable version which was uptodate. Will any of your changes be rolled into the official version so that it becomes self maintaining? > > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 4 ==========================** Date: Sun, 20 Oct 2002 14:50:14 +0200 From: Andreas Buening Subject: Re: gettext 0.11.5 John Poltorak wrote: > > On Sun, Oct 20, 2002 at 12:24:20AM +0200, Andreas Buening wrote: > > Hello! > > > > Some news: > > > > iconv/2 0.2.1: some bug fixes, iso-8859-15 added. > > > > > > gettext 0.11.5: > > http://unix.os2site.com/sw/binary/gettext/gettext-0_11_5-bin.zip > > > > The precompiled version (some executables, to be exactly) relies on > > libunixos2 0.1.1 (and iconv2/2 0.2.1 which is linked statically). > > 0.11.5 is forward and backward compatible to 0.10.35 and 0.10.39. > > Note: If you have problems with gettext there is a special > > debug dll version (gettext-0_11_5-bin-debug.zip) > > that prints some info to stderr. > > Is the source also available? Sure. sources are in .../source/gettext/, binaries in .../binary/gettext/... > I've been waiting a long time to find an easily buildable version which > was uptodate. Ehm, we are talking about gettext, this means it has as nothing to with "easy" or "simple" or "fast" or similar adjectives. ;-) In principle it works out of the box but you'd better use the flags from the README files. > Will any of your changes be rolled into the official version so that it > becomes self maintaining? I'll submit the changes if that's your question. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 5 ==========================** Date: Sun, 20 Oct 2002 15:39:18 +0200 From: Andreas Buening Subject: Re: problems with zlib114 Franz Bakan wrote: > > On Sat, 19 Oct 2002 23:30:13 +0200, Andreas Buening wrote: > > >> z.dll from zlib114.zip is not backwards-compatible to > >> the 113-version. > [snip] > >Eh, do you want to say that both dlls have different names? > > No, both contain (besides doc, diff, z.a, z.lib) a z.dll Okay, in this case you can do what I did with the gettext library: Find out which symbols are exported by those dlls (you can use "emxexp -u" on a static library). There are three kinds of symbols: 1) The documented library interface. It must never change, neither the name of the functions nor their declaration. I guess, it's unlikely that the maintainers have changed something in a minor version upgrade. 2) The undocumented functions that are used for internal purposes. Generally, no program uses them, so they don't matter. Their names and declarations may change between different versions. 3) Variables. Even if they aren't used in the program, their names have to be resolved at run time. This means if any version of libz has a variable foo that is exported, all further versions must also have this entry point. Find out which entry points are the problem, remove them (or add them) and recompile the latest version. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 6 ==========================** Date: Sun, 20 Oct 2002 18:20:42 +0200 (CEST) From: "Franz Bakan" Subject: Re: gettext 0.11.5 On Sun, 20 Oct 2002 00:24:20 +0200, Andreas Buening wrote: Hello Andreas, >gettext 0.11.5: After some testing I got the following results: 1. When I run XSane with this new intl.dll I get: Process terminated by SIGILL core dumped SYS1808: Der Prozeß wurde gestoppt. Der Softwarediagnosecode (Fehlercode der Ausnahmebedingung) ist 009D. POPUPLOG.OS2 says: 10-20-2002 17:44:03 SYS3186 PID 0048 TID 0001 Slot 0069 G:\XFREE86\BIN\XSANE.EXE c000009d 1de32cf8 EAX=00000001 EBX=0288ffcc ECX=00000001 EDX=029d0240 ESI=0001001e EDI=00000007 DS=0053 DSACC=d0f3 DSLIM=7fffffff ES=0053 ESACC=d0f3 ESLIM=7fffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1de32cf8 CSACC=d0df CSLIM=7fffffff SS:ESP=0053:0288fdac SSACC=d0f3 SSLIM=7fffffff EBP=0288fdd4 FLG=00012216 INTL.DLL 0001:00002cf8 2. Using the debug-version of intl.dll: When I run make --version (version 3.79.1 | 99840 19.05.02) I get: DEBUG(gettext): set_binding_values(): LOCALEDIR=/usr/share/locale (default) DEBUG(gettext): set_binding_values(): new binding directory: c:/usr/share/locale DEBUG(gettext): dcigettext(): LOCALEDIR=/usr/share/locale (default) DEBUG(gettext): _nl_expand_alias(): LOCALE_ALIAS_PATH=G:/usr/share/locale DEBUG(gettext): read_alias_file(): open locale alias file G:/usr/share/locale/locale.alias (success) DEBUG(gettext): _nl_load_domain(): reading message file c:/usr/share/locale/de/LC_MESSAGES/make.mo (failed) (Thats all, no version-info) When running make --version with the non-debug-version make does just nothing and exits without error-message. When I run the 2.79.2 version of make I get the same errormessages _but_ followed by the version-info. So everything seems OK. 3. the gettext-tools seem to work without problems in the build-process of Sane. Regards, Franz **= Email 7 ==========================** Date: Sun, 20 Oct 2002 21:01:34 +0200 From: Andreas Buening Subject: Re: gettext 0.11.5 Franz Bakan wrote: > > On Sun, 20 Oct 2002 00:24:20 +0200, Andreas Buening wrote: > > Hello Andreas, > > >gettext 0.11.5: > > After some testing I got the following results: > > 1. > When I run XSane with this new intl.dll I get: > > Process terminated by SIGILL > core dumped If you compiled xsane with gettext 0.11.x (x < 5) then the behaviour is expected. I decided to keep forward and backward compatibility with 0.10.35 and 0.10.39, i.e. programs compiled with one of these versions will run with any other version. Programs compiled with 0.11.5 and newer versions will run also with 0.11.x, but not vice versa. As an alternative I could add some dummy entry points for programs compiled with 0.11.x but this would mean that programs compiled with 0.11.x and newer versions won't work with 0.10.x. I'd prefer the first solution (like it is now). I hope that there aren't yet that many programs that rely on 0.11.x. I'm sorry but I'd like keep the current solution unless it turns out that there are too many compiled programs relying on 0.11.x. > 2. > Using the debug-version of intl.dll: > When I run make --version (version 3.79.1 | 99840 19.05.02) I get: > > DEBUG(gettext): set_binding_values(): LOCALEDIR=/usr/share/locale (default) > DEBUG(gettext): set_binding_values(): new binding directory: c:/usr/share/locale > DEBUG(gettext): dcigettext(): LOCALEDIR=/usr/share/locale (default) > DEBUG(gettext): _nl_expand_alias(): LOCALE_ALIAS_PATH=G:/usr/share/locale > DEBUG(gettext): read_alias_file(): open locale alias file G:/usr/share/locale/locale.alias (success) > DEBUG(gettext): _nl_load_domain(): reading message file c:/usr/share/locale/de/LC_MESSAGES/make.mo (failed) > > (Thats all, no version-info) > When running make --version with the non-debug-version make does just nothing and exits without error-message. > > When I run the 2.79.2 version of make I get the same errormessages _but_ > followed by the version-info. So everything seems OK. What is your UNIXROOT, GNULOCALEDIR (it's deprecated now) and which make do you have really installed and where? [snip] Thanks for your bug report. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 8 ==========================** Date: Sun, 20 Oct 2002 23:15:54 +0200 (CEST) From: "Franz Bakan" Subject: Re: gettext 0.11.5 On Sun, 20 Oct 2002 21:01:34 +0200, Andreas Buening wrote: >> Process terminated by SIGILL >> core dumped > > >If you compiled xsane with gettext 0.11.x (x < 5) then the >behaviour is expected. ... xsane was compiled using gcc3.0.3 with libintl.a produced by sources contained in the xsane-source-package. I don't know the version. But if I link with 0.10.35 intl.a instead of the 'internal' same coredump. If I link with 0.11.5 intl.a and iconv2.a same coredump. Very likely XSane does not load intl.dll itself. XSane as well as XScanimage depend on GTK (GimpToolKit) dlls which need a working intl.dll Also XScanimage from SANE built with gcc 2.8.1 and 0.10.35 intl.a results with: 10-20-2002 22:49:01 SYS3186 PID 0363 TID 0001 Slot 006a G:\TEST\109\281\XSCANIMAGE-NO-GIMP.EXE c000009d 17d029e8 EAX=17e44224 EBX=0282f9a4 ECX=00000000 EDX=0282f8e4 ESI=0282f970 EDI=00000000 DS=0053 DSACC=d0f3 DSLIM=7fffffff ES=0053 ESACC=d0f3 ESLIM=7fffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:17d029e8 CSACC=d0df CSLIM=7fffffff SS:ESP=0053:0282f91c SSACC=d0f3 SSLIM=7fffffff EBP=0282f950 FLG=00012246 INTL.DLL 0001:000029e8 ... >> 2. >> Using the debug-version of intl.dll: >> When I run make --version (version 3.79.1 | 99840 19.05.02) I get: >> >> DEBUG(gettext): set_binding_values(): LOCALEDIR=/usr/share/locale (default) >> DEBUG(gettext): set_binding_values(): new binding directory: c:/usr/share/locale >> DEBUG(gettext): dcigettext(): LOCALEDIR=/usr/share/locale (default) >> DEBUG(gettext): _nl_expand_alias(): LOCALE_ALIAS_PATH=G:/usr/share/locale >> DEBUG(gettext): read_alias_file(): open locale alias file G:/usr/share/locale/locale.alias (success) >> DEBUG(gettext): _nl_load_domain(): reading message file >> c:/usr/share/locale/de/LC_MESSAGES/make.mo (failed) >> >> (Thats all, no version-info) >> When running make --version with the non-debug-version make >> does just nothing and exits without error-message. >> >> When I run the 2.79.2 version of make I get the same errormessages _but_ >> followed by the version-info. So everything seems OK. > >What is your UNIXROOT, GNULOCALEDIR (it's deprecated now) UNIXROOT=G: GNULOCALEDIR=G:/usr/share/locale also if I set gnulocaledir empty before running the 3.79.1 make-version does not help. but I have some more information from popuplog.os2 10-20-2002 22:55:52 SYS2070 PID 036e TID 0001 Slot 007c G:\TEST\GETTEXT\MAKE.EXE MAKE->INTL.dcgettext__ 127 >and which make do you have really installed and where? installed is: make-3_79_2a1-bin.zip 405754 but for testing (to be true, this was not 'a planed test', I was executing the older make-version by accident) I exexuted the other make.exe (version 3.79.1 | 99840 19.05.02) (but I still have the newer gettext.mo files in G:\usr\share\locale\ when executing the older version.) Franz