From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 3 Apr 2002 04:23:15 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 183 ************************************************** Tuesday 02 April 2002 Number 183 ************************************************** Subjects for today 1 Re: BISON v1.35 : Jun Sawataishi 2 Re: iconv.a : Thomas Dickey 3 Re: GREP v2.5 : Dave and Natalie" 4 Wrong OBJ format when building BZIP2 : John Poltorak 5 Re: Wrong OBJ format when building BZIP2 : John Poltorak 6 Re: GREP v2.5 : John Poltorak 7 Re: GREP v2.5 : John Poltorak 8 Re: Wrong OBJ format when building BZIP2 : John Poltorak 9 Re: Multi-user OS/2 : Holger Veit 10 Re: Wrong OBJ format when building BZIP2 : John Poltorak 11 Re: Boost. Battle II. : Thomas Dickey 12 Re: Wrong OBJ format when building BZIP2 : John Poltorak 13 Re: Wrong OBJ format when building BZIP2 : Stefan Neis 14 Re: iconv.a : Holger Veit 15 SashXB : email at eracc.hypermart.net 16 Re: Wrong OBJ format when building BZIP2 : Holger Veit 17 Re: Wrong OBJ format when building BZIP2 : Holger Veit 18 Re: iconv.a : Andrew Zabolotny" 19 Re: Wrong OBJ format when building BZIP2 : Henry Sobotka 20 Re: Wrong OBJ format when building BZIP2 : Andrew Zabolotny" 21 Building GZIP with gcc v3.0.3 : John Poltorak 22 Re: Re: Building Perl.exe as a test of manhood ;-) : csaba.raduly at sophos.com 23 Hi folks! : Jack Troughton 24 Re: Boost. Battle II. : csaba.raduly at sophos.com 25 Re: Building GetText : Dave and Natalie" 26 Re: Wrong OBJ format when building BZIP2 : csaba.raduly at sophos.com 27 Re: Wrong OBJ format when building BZIP2 : csaba.raduly at sophos.com 28 Re: GREP v2.5 : Dave and Natalie" 29 Re: Building GZIP with gcc v3.0.3 : John Poltorak 30 Re: Wrong OBJ format when building BZIP2 : Brian Havard" 31 Re: Wrong OBJ format when building BZIP2 : Brian Havard" 32 Re: Need some help builing GETTEXT : John Poltorak 33 Re: Hi folks! : Jack Troughton **= Email 1 ==========================** Date: Wed, 03 Apr 2002 00:33:44 +0900 From: Jun Sawataishi Subject: Re: BISON v1.35 At Mon, 1 Apr 2002 09:26:04 +0000, John Poltorak wrote: > There's a new version of BISON (1.35) at GNU. See:- > ftp://ftp.gnu.org/pub/gnu/bison/bison-1.35.tar.gz After executing "os2unix -all", I did this way. $ configure --disable-dependency-tracking $ make - GNU intl library 0.11.1: failed to compile ==> replaced with one included in gettext 0.10.40 - Using `unixrootify ()' hard coded file names are fixed #ifndef __EMX__ skeleton = skeleton_find ("BISON_HAIRY", BISON_HAIRY); #else skeleton = skeleton_find ("BISON_HAIRY", unixrootify(BISON_HAIRY)); #endif /* __EMX__ */ else #ifndef __EMX__ skeleton = skeleton_find ("BISON_SIMPLE", BISON_SIMPLE); #else skeleton = skeleton_find ("BISON_SIMPLE", unixrootify(BISON_SIMPLE)); #endif /* __EMX__ */ I just built it, which seems to work fine. But I was not able to fix scripts for test: failed to execute "make check". # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 2 ==========================** Date: Wed, 3 Apr 2002 05:23:49 -0500 From: Thomas Dickey Subject: Re: iconv.a On Wed, Apr 03, 2002 at 11:51:47AM +0200, Holger Veit wrote: > As said, this typically happens when you declare variables in a DLL segment, > but don't initialize them with a default value. Things like > > struct foo { > int bar,baz; > }; > > struct foo somevar; > struct foo *someptr; > > are typically the reason for the problem. I have modified several instances > of such global variables in XFree86 DLLs to become initialized. By default, > one would assume that they will be initialized correctly with 0, but they > land in the .DATA segment rather than .COMMON or .BSS (or vice versa, don't probably BSS (I worked on a project which exploited this difference to generate code which could be burned onto PROM's). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 3 ==========================** Date: Wed, 03 Apr 2002 08:10:47 -0800 From: "Dave and Natalie" Subject: Re: GREP v2.5 On Wed, 3 Apr 2002 09:09:07 +0000, John Poltorak wrote: > >I don't get so far... I think that a successfull build and install of >GETTEXT must be a pre-requisite and I'm having a hard time getting the >latest GETTEXT to build... > All I've installed from the latest gettext so far is intl.dll to see if anything broke. > >How are the tests run? 'Make test'? > Make check Dave **= Email 4 ==========================** Date: Wed, 3 Apr 2002 08:25:57 +0000 From: John Poltorak Subject: Wrong OBJ format when building BZIP2 When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile from here:- http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip I get OBJ files created with a .o extension. Can anyone suggest what I'm doing wrong? It has built correctly in the past. Could the difference be accounted for by my use of gcc 3.0.3 instead of 2.8.1? -- John **= Email 5 ==========================** Date: Wed, 3 Apr 2002 08:53:31 +0000 From: John Poltorak Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 10:44:36AM +0200, Stefan Neis wrote: > On Wed, 3 Apr 2002, John Poltorak wrote: > > > > > When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile > > from here:- > > > > http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip > > > > I get OBJ files created with a .o extension. > > > > Can anyone suggest what I'm doing wrong? > > Why would that be a problem? As long as the right tools/flags are used, > the extension shouldn't matter either way. This Makefile depends on the .obj extension:- SHELL=sh # To assist in cross-compiling CC=gcc AR=emxomfar LDFLAGS=-s -Zomf # Suitably paranoid flags to avoid bugs in gcc-2.7 #BIGFILES=-D_FILE_OFFSET_BITS=64 CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) # Where you want it installed when you do 'make install' PREFIX=/usr OBJS= blocksort.obj \ huffman.obj \ crctable.obj \ randtable.obj \ compress.obj \ decompress.obj \ bzlib.obj all: bz2.lib bzip2.exe bzip2recover.exe test bzip2.exe: bz2.dll bz2.lib bzip2.obj $(CC) $(CFLAGS) $(LDFLAGS) -o $ at bzip2.obj -L. -lbz2 bzip2recover.exe: bzip2recover.obj $(CC) $(CFLAGS) $(LDFLAGS) -o $ at bzip2recover.obj bz2.lib: bz2.def rm -f bz2.lib emximp -o $ at $< bz2.def: $(OBJS) echo "LIBRARY $* INITINSTANCE" > $ at echo "DATA NONSHARED" >> $ at echo "EXPORTS" >> $ at emxexp $(OBJS) >> $ at bz2.dll: $(OBJS) bz2.def $(CC) $(CFLAGS) $(LDFLAGS) -Zdll -o $ at $(OBJS) bz2.def > Regards, > Stefan -- John **= Email 6 ==========================** Date: Wed, 3 Apr 2002 09:09:07 +0000 From: John Poltorak Subject: Re: GREP v2.5 On Tue, Apr 02, 2002 at 01:19:46PM -0800, Dave and Natalie wrote: > On Mon, 1 Apr 2002 08:59:01 +0000, John Poltorak wrote: > > > > >A new release of GREP (v2.5) appeared at GNU a couple of weeks ago. See:- > > > >ftp://ftp.gnu.org/pub/gnu/grep/grep-2.5.tar.gz > > > >Wonder if this will build on OS/2 straight out of the box... > > Well configure --prefix=/usr ran fine right out of the box (no autoconf), picked up on exe as an executable extension and for a change didn't think I was cross-compiling. I don't get so far... I think that a successfull build and install of GETTEXT must be a pre-requisite and I'm having a hard time getting the latest GETTEXT to build... > Running make first failed on make.com in the vms directory. Then failed building grep.info, most likely due to my texi install. > make[2]: Entering directory `/usr/src/grep-2.5/doc' > cd . \ > && makeinfo --no-split \ > `echo grep.texi | sed 's,.*/,,'` > ./version.texi:84: Unknown command `(#)PD'. > makeinfo: Removing output file `/usr/src/grep-2.5/doc/grep.info' due to errors; use --force to preserve. > make[2]: *** [grep.info] Error 2 > > I had to patch src/grep.c by adding this near the top of the file > #ifdef __EMX__ > #define strcasecmp stricmp > #define S_ISBLK(x) (0) > #endif > Then it built nicely. No emxbind required. I do get 3 of 10 tests failing though. And as pointed out by Mr. Sawataishi it doesn't support wild-cards etc. How are the tests run? 'Make test'? Maybe I should test GREP v2.4.2 to see how well that performs... > Dave -- John **= Email 7 ==========================** Date: Wed, 3 Apr 2002 09:17:24 +0000 From: John Poltorak Subject: Re: GREP v2.5 On Tue, Apr 02, 2002 at 11:18:43PM +0900, Jun Sawataishi wrote: > At Mon, 1 Apr 2002 08:59:01 +0000, > John Poltorak wrote: > > A new release of GREP (v2.5) appeared at GNU a couple of weeks ago. See:- > > ftp://ftp.gnu.org/pub/gnu/grep/grep-2.5.tar.gz > > Wonder if this will build on OS/2 straight out of the box... > Using `os2unix' utility, I was able to built it "out of the box". The configure script included with GREP v2.5 should be able to run without any amendments. If this is correct, then the Autoconf developers have done a good job in making it cross platform which is something I having been waiting for for a long time, since it puts OS/2 on a level playing field with other apps where you can simply run configure and make. > But modification on source codes is needed to handle wild cards > and to recognize directory. > > $ configure --disable-dependency-tracking > $ make > > I recommend you to apply a diff file (C_Source.diff) for grep 2.5a. > http://homepage1.nifty.com/jsawa/gnu/grep-2.5a-OS2-patch.zip > > # OS/2 is not a question, it's a solution. > # SAWATAISHI Jun > # http://www2s.biglobe.ne.jp/~vtgf3mpr/ -- John **= Email 8 ==========================** Date: Wed, 3 Apr 2002 09:36:04 +0000 From: John Poltorak Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 07:12:10PM +1000, Brian Havard wrote: > On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > > > > >When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile > >from here:- > > > >http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip > > > >I get OBJ files created with a .o extension. > > > >Can anyone suggest what I'm doing wrong? > > > >It has built correctly in the past. Could the difference be accounted for > >by my use of gcc 3.0.3 instead of 2.8.1? > > What make are you using? The makefile has no .c.obj: implicit rule so it > will be using the make's built-in rule. If that built-in rule doesn't use > CFLAGS it won't get the -Zomf & will compile a.out .o files. I'm using make v3.79.1 in both instances. Wondered if you had a gcc v3.0.3 environment anywhere... If anyone does have 3.0.3 installed could you try building BZIP2 v1.0.2 by applying the patch and Makefile from:- http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip to:- ftp://sources.redhat.com/pub/bzip2/v102/bzip2-1.0.2.tar.gz > I'm using a sligtly tweaked make 3.76.1, as described on > http://silk.apana.org.au/apache/building.html Do you know if your tweaks are incorporated in v3.79.1? It would be useful to try and get a standardised tool set established. Different versions of Make seem to have been a major culprit of build failures in my experience, and there are several builds of 3.76.1 available which confuses things even more. > -- > ______________________________________________________________________________ > | Brian Havard | "He is not the messiah! | > | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | > ------------------------------------------------------------------------------ -- John **= Email 9 ==========================** Date: Wed, 3 Apr 2002 09:42:45 +0200 From: Holger Veit Subject: Re: Multi-user OS/2 On Tue, Apr 02, 2002 at 02:57:39PM +0000, John Poltorak wrote: > > I just noticed an item about a third party multi-user support enhancement > for OS/2 here:- > > http://www.os2bbs.com/os2news/ > > > Does anyone know how this will work? > > Is there any chance of this working with a PASSWD file? I assume it uses > NET.ACC. If so is there a way of synchronising this with PASSWD entries? > > Or alternatively could LIBEMU get user and group information from > somewhere apart from /etc/passwd and /etc/group ? It is likely using SES. Whether its database can be tapped for uses of Unix, depends on the interfaces implemented. In theory, everything is possible, but this software is just announced, so noone can say what it really does. If it is a "classical" SES system, it will use numerous processes to ensure certain aspects of security (e.g. local/remote login) - the SES highlevel architecture is not really an efficient and small system. And it is difficult to make it really multi-user; the typical application field that the SES highlevel system was made for is single console login + a few remote daemon services. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 10 ==========================** Date: Wed, 3 Apr 2002 09:43:41 +0000 From: John Poltorak Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 01:14:18PM +0400, Andrew Zabolotny wrote: > On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > > >I get OBJ files created with a .o extension. > >It has built correctly in the past. Could the difference be accounted for > >by my use of gcc 3.0.3 instead of 2.8.1? > Exactly. At some point I've decided to drop off the patches that made gcc > generate .o or .obj files depending on whether the -Zomf switch is given or not. > This was caused by a major architectural change to the gcc preprocessor in gcc > 3.0 and I've decided to drop these dirty patches altogether. If you want .obj > files you have to explicitely say "-o file.obj". So does this no longer work? CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) blocksort.obj: blocksort.c at cat words0 $(CC) $(CFLAGS) -c blocksort.c huffman.obj: huffman.c $(CC) $(CFLAGS) -c huffman.c crctable.obj: crctable.c $(CC) $(CFLAGS) -c crctable.c randtable.obj: randtable.c $(CC) $(CFLAGS) -c randtable.c compress.obj: compress.c $(CC) $(CFLAGS) -c compress.c decompress.obj: decompress.c $(CC) $(CFLAGS) -c decompress.c bzlib.obj: bzlib.c $(CC) $(CFLAGS) -c bzlib.c bzip2.obj: bzip2.c $(CC) $(CFLAGS) -c bzip2.c bzip2recover.obj: bzip2recover.c $(CC) $(CFLAGS) -c bzip2recover.c What needs to be changed? > > Greetings, > _\ndy > -- John **= Email 11 ==========================** Date: Wed, 3 Apr 2002 10:07:12 -0500 From: Thomas Dickey Subject: Re: Boost. Battle II. On Wed, Apr 03, 2002 at 03:48:40PM +0100, csaba.raduly at sophos.com wrote: > > On 27/03/2002 06:57:46 owner-os2-unix wrote: > > [snip] > > > >I noticed the GCC V.3 libraries put a lot of files in g++-v3 that > >look like .h files, but they have no extension. What's with that? > > > > STL (standard template library) most likely > :-(whoever had the idea of no extensions should be beaten)-: not exactly. my impression is that it is an accommodation for systems where the headers may be compiled and put into libraries for performance reasons. (some systems don't implement filenames per se in that context). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 12 ==========================** Date: Wed, 3 Apr 2002 10:29:06 +0000 From: John Poltorak Subject: Re: Wrong OBJ format when building BZIP2 > > CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) > > > > blocksort.obj: blocksort.c > > at cat words0 > > $(CC) $(CFLAGS) -c blocksort.c > > huffman.obj: huffman.c > > $(CC) $(CFLAGS) -c huffman.c > > crctable.obj: crctable.c > > $(CC) $(CFLAGS) -c crctable.c > > randtable.obj: randtable.c > > $(CC) $(CFLAGS) -c randtable.c > > compress.obj: compress.c > > $(CC) $(CFLAGS) -c compress.c > > decompress.obj: decompress.c > > $(CC) $(CFLAGS) -c decompress.c > > bzlib.obj: bzlib.c > > $(CC) $(CFLAGS) -c bzlib.c > > bzip2.obj: bzip2.c > > $(CC) $(CFLAGS) -c bzip2.c > > bzip2recover.obj: bzip2recover.c > > $(CC) $(CFLAGS) -c bzip2recover.c > > > > > > > > What needs to be changed? > > If I understood correctly, you'd have to explicitly specify -o file.obj. > But you better throw away the useless -Zomf. I added '-o $ at ' in CFLAGS and this worked OK, although the binaries are now linked with GCC303M which becomes a required DLL and the EXEs are slightly bigger than before. When I removed -Zomf, I got:- blocksort.obj : fatal error L1101: invalid object module Object file offst: 1 Record type: 07 make: *** [bz2.dll] Error 1 It looks like migrating to gcc 3.0.3 takes us to the bleeding edge, but I guess we have to rise to the challenge... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) -- John **= Email 13 ==========================** Date: Wed, 3 Apr 2002 10:44:36 +0200 (CEST) From: Stefan Neis Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 3 Apr 2002, John Poltorak wrote: > > When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile > from here:- > > http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip > > I get OBJ files created with a .o extension. > > Can anyone suggest what I'm doing wrong? Why would that be a problem? As long as the right tools/flags are used, the extension shouldn't matter either way. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 14 ==========================** Date: Wed, 3 Apr 2002 11:51:47 +0200 From: Holger Veit Subject: Re: iconv.a On Wed, Apr 03, 2002 at 01:09:34PM +0400, Andrew Zabolotny wrote: > On Tue, 2 Apr 2002 11:20:12 +0000, John Poltorak wrote: > > >> >Any idea what could be causing this? > >> Yes. Use emxbind from gcc 3.0.3. The original emxbind is unable to export > >> data symbols. > >Is it a requirement to upgrade to gcc 3.0.3 to be able to build the latest > >INTL.DLL ? > I don't know. I've used 3.0.3 but I believe you can use 2.8.1 by using the newer > emxbind and uconv.h. The problem is that emxbind is unable to export > uninitialized variables from the .data segment or something like that, I don't > remember the problem exactly now. If you're interested, you can look in the diff > file for emxbind, I've documented it there. As said, this typically happens when you declare variables in a DLL segment, but don't initialize them with a default value. Things like struct foo { int bar,baz; }; struct foo somevar; struct foo *someptr; are typically the reason for the problem. I have modified several instances of such global variables in XFree86 DLLs to become initialized. By default, one would assume that they will be initialized correctly with 0, but they land in the .DATA segment rather than .COMMON or .BSS (or vice versa, don't remmeber, at least in a place where emxbind doesn't like them). So simply modify the offending source code, here: struct foo somevar = { 0,0 }; struct foo *someptr = 0; The point is that such source code relies on an implicit assumption that the variables are correctly initialized (usually with 0) because when the data segment is loaded, it will have some initial value pattern. But such an implicit assumption is a Bad Thing(tm); so the code is defective in some way. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 15 ==========================** Date: Wed, 03 Apr 2002 11:54:52 -0600 From: email at eracc.hypermart.net Subject: SashXB Hi Porting Gurus, Since I am still just dabbling my toes in the waters of ported SW from Linux to OS/2 I can't evaluate my question myself. Thus, what are the learned opinions of those of you with ability to port about the SashXB software from IBM being ported to (ironically) IBM's OS/2? Here is a URL from which to start: http://www-124.ibm.com/developerworks/oss/sashxb/ I would enjoy reading your opinions. TIA. Gene -- +=========================-=>Unix & OS/2<=-=========================+ # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # # OS/2, UnixWare, OpenServer & Linux Business Computing Solutions # # Please visit our www pages at http://eracc.hypermart.net/ # +===================================================================+ We run IBM OS/2 v.4.00, Revision 9.036 Sysinfo: 38 Processes, 160 Threads, uptime is 22d 20h 51m 7s 230ms **= Email 16 ==========================** Date: Wed, 3 Apr 2002 11:55:45 +0200 From: Holger Veit Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 01:14:18PM +0400, Andrew Zabolotny wrote: > On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > > >I get OBJ files created with a .o extension. > >It has built correctly in the past. Could the difference be accounted for > >by my use of gcc 3.0.3 instead of 2.8.1? > Exactly. At some point I've decided to drop off the patches that made gcc > generate .o or .obj files depending on whether the -Zomf switch is given or not. > This was caused by a major architectural change to the gcc preprocessor in gcc > 3.0 and I've decided to drop these dirty patches altogether. If you want .obj > files you have to explicitely say "-o file.obj". You are implying that the .o file that results from the compile is effectively an OMF file? This would solve certain problems with makefiles, but will cause severe problems when touched with the wrong linker/archivers. If true, it sounds to me like a very bad idea (OTOH, it would be good to abolish the OMF files entirely, rather use a separate conversion utility if one really wanted to have .obj files for some external compile. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 17 ==========================** Date: Wed, 3 Apr 2002 12:03:49 +0200 From: Holger Veit Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 09:43:41AM +0000, John Poltorak wrote: > On Wed, Apr 03, 2002 at 01:14:18PM +0400, Andrew Zabolotny wrote: > > On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > > > > >I get OBJ files created with a .o extension. > > >It has built correctly in the past. Could the difference be accounted for > > >by my use of gcc 3.0.3 instead of 2.8.1? > > Exactly. At some point I've decided to drop off the patches that made gcc > > generate .o or .obj files depending on whether the -Zomf switch is given or not. > > This was caused by a major architectural change to the gcc preprocessor in gcc > > 3.0 and I've decided to drop these dirty patches altogether. If you want .obj > > files you have to explicitely say "-o file.obj". > > > So does this no longer work? It will probably compile, but no longer link, because the linker rule won't find any .obj files. The point is that there is no reason at all here to produce OMF files. Why would one need them? OMF is the native object file format, so you need them only if you like to build a .LIB library that is to be used with foreign software. However, you cannot link EMX objs well with objs produced by a non-gcc compiler, but only with code produced by gcc -Zomf. This is where the cat bites its tail. > CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) > > blocksort.obj: blocksort.c > at cat words0 > $(CC) $(CFLAGS) -c blocksort.c > huffman.obj: huffman.c > $(CC) $(CFLAGS) -c huffman.c > crctable.obj: crctable.c > $(CC) $(CFLAGS) -c crctable.c > randtable.obj: randtable.c > $(CC) $(CFLAGS) -c randtable.c > compress.obj: compress.c > $(CC) $(CFLAGS) -c compress.c > decompress.obj: decompress.c > $(CC) $(CFLAGS) -c decompress.c > bzlib.obj: bzlib.c > $(CC) $(CFLAGS) -c bzlib.c > bzip2.obj: bzip2.c > $(CC) $(CFLAGS) -c bzip2.c > bzip2recover.obj: bzip2recover.c > $(CC) $(CFLAGS) -c bzip2recover.c > > > > What needs to be changed? If I understood correctly, you'd have to explicitly specify -o file.obj. But you better throw away the useless -Zomf. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 18 ==========================** Date: Wed, 03 Apr 2002 13:09:34 +0400 From: "Andrew Zabolotny" Subject: Re: iconv.a On Tue, 2 Apr 2002 11:20:12 +0000, John Poltorak wrote: >> >Any idea what could be causing this? >> Yes. Use emxbind from gcc 3.0.3. The original emxbind is unable to export >> data symbols. >Is it a requirement to upgrade to gcc 3.0.3 to be able to build the latest >INTL.DLL ? I don't know. I've used 3.0.3 but I believe you can use 2.8.1 by using the newer emxbind and uconv.h. The problem is that emxbind is unable to export uninitialized variables from the .data segment or something like that, I don't remember the problem exactly now. If you're interested, you can look in the diff file for emxbind, I've documented it there. Greetings, _\ndy **= Email 19 ==========================** Date: Wed, 03 Apr 2002 13:11:38 -0500 From: Henry Sobotka Subject: Re: Wrong OBJ format when building BZIP2 Holger Veit wrote: > > You are implying that the .o file that results from the compile is effectively > an OMF file? This would solve certain problems with makefiles, but will cause > severe problems when touched with the wrong linker/archivers. If true, it > sounds to me like a very bad idea (OTOH, it would be good to abolish the > OMF files entirely, rather use a separate conversion utility if one really > wanted to have .obj files for some external compile. What's the rationale behind the statement in the EMX docs that OMF is better for DLLs? Years ago I asked EM about it and just got a "Why would you want to do it any other way?" reply. h~ **= Email 20 ==========================** Date: Wed, 03 Apr 2002 13:14:18 +0400 From: "Andrew Zabolotny" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: >I get OBJ files created with a .o extension. >It has built correctly in the past. Could the difference be accounted for >by my use of gcc 3.0.3 instead of 2.8.1? Exactly. At some point I've decided to drop off the patches that made gcc generate .o or .obj files depending on whether the -Zomf switch is given or not. This was caused by a major architectural change to the gcc preprocessor in gcc 3.0 and I've decided to drop these dirty patches altogether. If you want .obj files you have to explicitely say "-o file.obj". Greetings, _\ndy **= Email 21 ==========================** Date: Wed, 3 Apr 2002 14:42:28 +0000 From: John Poltorak Subject: Building GZIP with gcc v3.0.3 Following discussions earlier about architectural changes in gcc v3.0.3, I presume GZIP will now not build using the suppled Makefile.os2... It's available here, BTW:- ftp://gatekeeper.dec.com/pub/GNU/gzip/gzip-1.2.4.tar.gz It does work OK with gcc v2.8.1 but if we are going to move forward, what is the recommended way of building GZIP? Should we forget the OS/2 specific Makefile and build it via configure? Incidentally, I think I've seen references to a new version of GZIP recently, has anyone else seen it? -- John **= Email 22 ==========================** Date: Wed, 3 Apr 2002 15:28:43 +0100 From: csaba.raduly at sophos.com Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On 26/03/2002 15:15:16 Edwin Günthner wrote: >csaba.raduly at sophos.com wrote: > >> defined fork() or die "Error: $!"; > >You are right. That's the think that I love >about Perl: for open it is "open or die" >and for fork it is like above ... > Typical Perl booby trap. Most functions return undef on failure, which evaluates to false in "boolean" context (i.e. an if statement ). In truth, one should always use "if defined foo" as long as foo returns undef on failure. Most of the time foo never returns 0, only non-zero or undef. However, when 0 _is_ a valid return value (as it's the case with fork), you'll get burned if you used the shorthand version :-) -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 23 ==========================** Date: Wed, 03 Apr 2002 15:48:01 -0500 From: Jack Troughton Subject: Hi folks! Hi there! I suddenly find myself in need of a good bind... which is the current port right now? I downloaded the 824 port from Hobbes, but can't get on to the unixos2.com ftp site to see what they have there... hence my asking here. Any comments on the ddns that's included in the new stacks? Regards, Jack (who just got ecomstation.ca and consultron.ca registered and wants to set it up) -- ------------------------------------------------------------------- * Jack Troughton jake at jakesplace.dhs.org * * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * * Montr‚al PQ Canada news://jakesplace.dhs.org * ------------------------------------------------------------------- **= Email 24 ==========================** Date: Wed, 3 Apr 2002 15:48:40 +0100 From: csaba.raduly at sophos.com Subject: Re: Boost. Battle II. On 27/03/2002 06:57:46 owner-os2-unix wrote: [snip] > >I noticed the GCC V.3 libraries put a lot of files in g++-v3 that >look like .h files, but they have no extension. What's with that? > STL (standard template library) most likely :-(whoever had the idea of no extensions should be beaten)-: -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 25 ==========================** Date: Wed, 03 Apr 2002 16:15:28 -0800 From: "Dave and Natalie" Subject: Re: Building GetText Well first I thought my build of Gettext was broken. Kept getting 04-01-2002 20:13:14 SYS2070 PID 09bd TID 0001 Slot 009e X:\USR\SRC\GETTEXT-0.11.1\OS2\OUT\RELEASE\GETTEXT.EXE GETTEXT->INTL._nl_getenv 127 Then I realized I had /usr/dll in front of . in my libpath. Anyways my new intl.dll seems to work fine with older apps. Dave **= Email 26 ==========================** Date: Wed, 3 Apr 2002 16:19:16 +0100 From: csaba.raduly at sophos.com Subject: Re: Wrong OBJ format when building BZIP2 On 03/04/2002 10:55:45 owner-os2-unix wrote: >On Wed, Apr 03, 2002 at 01:14:18PM +0400, Andrew Zabolotny wrote: >> On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: >> >> >I get OBJ files created with a .o extension. >> >It has built correctly in the past. Could the difference be accounted for >> >by my use of gcc 3.0.3 instead of 2.8.1? >> Exactly. At some point I've decided to drop off the patches that made gcc >> generate .o or .obj files depending on whether the -Zomf switch is given or >not. >> This was caused by a major architectural change to the gcc preprocessor in gcc >> 3.0 and I've decided to drop these dirty patches altogether. If you want .obj >> files you have to explicitely say "-o file.obj". > >You are implying that the .o file that results from the compile is effectively >an OMF file? This would solve certain problems with makefiles, but will cause >severe problems when touched with the wrong linker/archivers. If true, it >sounds to me like a very bad idea (OTOH, it would be good to abolish the >OMF files entirely, rather use a separate conversion utility if one really >wanted to have .obj files for some external compile. > IMHO this is similar to the ELF/a.out format differences. AFAIK both get the .o extension on e.g. Linux -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 27 ==========================** Date: Wed, 3 Apr 2002 16:23:40 +0100 From: csaba.raduly at sophos.com Subject: Re: Wrong OBJ format when building BZIP2 On 03/04/2002 11:03:49 Holger Veit wrote: [snip] > >> CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf >>-Zmtd $(BIGFILES) >> >> blocksort.obj: blocksort.c >> at cat words0 Huh ? Why is it prointing words0 on the terminal ? >> $(CC) $(CFLAGS) -c blocksort.c >> huffman.obj: huffman.c >> $(CC) $(CFLAGS) -c huffman.c >> crctable.obj: crctable.c >> $(CC) $(CFLAGS) -c crctable.c >> randtable.obj: randtable.c >> $(CC) $(CFLAGS) -c randtable.c >> compress.obj: compress.c >> $(CC) $(CFLAGS) -c compress.c >> decompress.obj: decompress.c >> $(CC) $(CFLAGS) -c decompress.c >> bzlib.obj: bzlib.c >> $(CC) $(CFLAGS) -c bzlib.c >> bzip2.obj: bzip2.c >> $(CC) $(CFLAGS) -c bzip2.c >> bzip2recover.obj: bzip2recover.c >> $(CC) $(CFLAGS) -c bzip2recover.c >> >> >> >> What needs to be changed? > >If I understood correctly, you'd have to explicitly specify -o file.obj. >But you better throw away the useless -Zomf. > Bah. Somebody teach these folks (who created the makefile) implicit rules. There's nothing wrong with -Zomf, as such. .c.obj: $(CC) $(CFLAGS) -c $< -o $ at (except for blocksort.c, which needs -o $ at at the end too) -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 28 ==========================** Date: Wed, 03 Apr 2002 16:33:24 -0800 From: "Dave and Natalie" Subject: Re: GREP v2.5 On Wed, 3 Apr 2002 09:17:24 +0000, John Poltorak wrote: > >The configure script included with GREP v2.5 should be able to run without >any amendments. If this is correct, then the Autoconf developers have done >a good job in making it cross platform which is something I having been >waiting for for a long time, since it puts OS/2 on a level playing field >with other apps where you can simply run configure and make. I tried running configure without my config.site and it died pretty quick while looking for gcc. Dave **= Email 29 ==========================** Date: Wed, 3 Apr 2002 17:50:13 +0000 From: John Poltorak Subject: Re: Building GZIP with gcc v3.0.3 On Wed, Apr 03, 2002 at 02:42:28PM +0000, John Poltorak wrote: > > Following discussions earlier about architectural changes in gcc v3.0.3, I > presume GZIP will now not build using the suppled Makefile.os2... > > > It's available here, BTW:- > > ftp://gatekeeper.dec.com/pub/GNU/gzip/gzip-1.2.4.tar.gz Here's what the OS/2 Makefile contains:- # compilation with emx 0.8f (gcc 2.3.3) or newer # # release version, statically linked C runtime gcc: $(MAKE) -f Makefile.os2 all \ CC="gcc -Zomf -Zsys" O=".obj" S=".S" \ AS="gcc -Zomf -xassembler-with-cpp -c -o" \ CFLAGS="-O" LDFLAGS="gzip.def -s" # # release version, dynamically linked C runtime gccdyn: $(MAKE) -f Makefile.os2 all \ CC="gcc -Zomf -Zmt" O=".obj" S=".S" \ AS="gcc -Zomf -xassembler-with-cpp -c -o" \ CFLAGS="-O" LDFLAGS="gzip.def -s" # # debugging version gccdebug: $(MAKE) -f Makefile.os2 all \ CC="gcc -g" O=".o" S=".S" \ AS="gcc -g -xassembler-with-cpp -c -o" \ CFLAGS="" LDFLAGS="gzip.def" If I change the 'gcc' version to O=".o" it works OK. Are there any other changes which need to be made? > > > It does work OK with gcc v2.8.1 but if we are going to move forward, what > is the recommended way of building GZIP? > > Should we forget the OS/2 specific Makefile and build it via configure? > > Incidentally, I think I've seen references to a new version of GZIP > recently, has anyone else seen it? Just found it here:- ftp://linux-rep.fnal.gov/pub/mirrors/gnu/alpha/gzip/gzip-1.3.3.tar.gz -- John **= Email 30 ==========================** Date: Wed, 03 Apr 2002 19:12:10 +1000 (EST) From: "Brian Havard" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > >When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile >from here:- > >http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip > >I get OBJ files created with a .o extension. > >Can anyone suggest what I'm doing wrong? > >It has built correctly in the past. Could the difference be accounted for >by my use of gcc 3.0.3 instead of 2.8.1? What make are you using? The makefile has no .c.obj: implicit rule so it will be using the make's built-in rule. If that built-in rule doesn't use CFLAGS it won't get the -Zomf & will compile a.out .o files. I'm using a sligtly tweaked make 3.76.1, as described on http://silk.apana.org.au/apache/building.html -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------ **= Email 31 ==========================** Date: Wed, 03 Apr 2002 19:36:49 +1000 (EST) From: "Brian Havard" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 03 Apr 2002 19:12:10 +1000 (EST), Brian Havard wrote: >On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > >> >>When building BZIP2 v1.0.2 with gcc 3.0.3 using the patch and Makefile >>from here:- >> >>http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2.zip >> >>I get OBJ files created with a .o extension. >> >>Can anyone suggest what I'm doing wrong? >> >>It has built correctly in the past. Could the difference be accounted for >>by my use of gcc 3.0.3 instead of 2.8.1? > >What make are you using? The makefile has no .c.obj: implicit rule so it >will be using the make's built-in rule. If that built-in rule doesn't use >CFLAGS it won't get the -Zomf & will compile a.out .o files. Ooops, no that's not right. There are explicit rules near the end of the makefile (I didn't look far enough). From what Andrew said, you'll have to add a -o switch to each of them. -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------ **= Email 32 ==========================** Date: Wed, 3 Apr 2002 21:15:39 +0000 From: John Poltorak Subject: Re: Need some help builing GETTEXT On Thu, Mar 28, 2002 at 03:09:44PM -0800, Dave and Natalie wrote: > On Thu, 28 Mar 2002 21:37:03 +0000, John Poltorak wrote: > > >> Then I got this > > > >I ended up with:- > > > >emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > > > >although on closer examination I do see an intl.a in os2\out\release.. > > > > > >Can I use this to make an INTL.DLL ? > > I don't know, I did end up with an INTL.DLL. I guess I should test this. An INTL.DLL has now mysteriously appeared within GETTEXT after hitting a random sequence of ketstrokes (never to be repeated) however when I view the file, I don't see any reference to _nl_msg_cat_cntr which is what I was hoping to find... BTW how do I list all the functions in a DLL? I'm sure it's one of those EMX* utils which I hardly ever use... > Dave -- John **= Email 33 ==========================** Date: Wed, 03 Apr 2002 23:32:05 -0500 From: Jack Troughton Subject: Re: Hi folks! Mikkel C. Simonsen wrote: > Jack Troughton wrote: > >>Hi there! >> >>I suddenly find myself in need of a good bind... which is the current >>port right now? > > 8.2.4 - works very well. > > If you (or somebody else) need a PM zone-file editor let me know... Sure... what's a zone file editor? I've got to crash course on how name servers work... >>I downloaded the 824 port from Hobbes, but can't get on to the >>unixos2.com ftp site to see what they have there... hence my asking here. > > > There are some changes in the Bind 9 code that makes it hard to compile > on OS/2 (or so I've heard...). But 8.2.4 works great. Ok, so the hobbes server is good then. Guess I got to go read up on how it works so I can set it up. >>Any comments on the ddns that's included in the new stacks? > > It used to be Bind 4 based - don't know about the newer versions. AFAIK, it still is... was wondering if that mattered a great deal or not. It does do the dynamic name stuff in conjunction with the dhcp server, which I thought might be useful in the future. Right now, though, I just need to get a couple of name servers running... as well as getting a second IP from my provider to put the backup server on. >>(who just got ecomstation.ca and consultron.ca registered and wants to >>set it up) -- ------------------------------------------------------------------- * Jack Troughton jake at jakesplace.dhs.org * * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * * Montréal PQ Canada news://jakesplace.dhs.org * -------------------------------------------------------------------