From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 9 Feb 2002 04:14:47 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 130 ************************************************** Friday 08 February 2002 Number 130 ************************************************** Subjects for today 1 Re: Sox 12.17.3 : Michel SUCH" 2 GNU OCR for OS/2 : John Poltorak 3 unchecked.h v. unchecke.h : John Poltorak 4 Multimedia headers : John Poltorak 5 Re: ipc.h : Holger Veit 6 Re: Building Perl with gcc v3.0.2 : Henry Sobotka 7 Re: Multimedia headers : Henry Sobotka 8 Re: GLIBC : Kees de LezenneCoulander 9 gcc 3.0.2 and configure problem : John Poltorak 10 Re: gcc 3.0.2 and configure problem : John Poltorak 11 Building Perl with gcc v3.0.2 : John Poltorak 12 Re: Multimedia headers : Ken Ames 13 Re: unchecked.h v. unchecke.h : Holger Veit 14 Re: Multimedia headers : Holger Veit 15 Re: Multimedia headers : John Poltorak 16 Re: unchecked.h v. unchecke.h : John Poltorak 17 make 3.79.1 and OS/2 "features" : Andreas Buening 18 Re: unchecked.h v. unchecke.h : Holger Veit **= Email 1 ==========================** Date: Sat, 09 Feb 2002 07:22:48 +0100 (CET) From: "Michel SUCH" Subject: Re: Sox 12.17.3 On Fri, 8 Feb 2002 21:10:18 +0000, John Poltorak wrote: > >Does anyone have a working builld of Sox 12.17.3 or even .2 ? > >I managed to build it but it didn't work correctly. > I have one, but there is a problem in command line parsing I reported to author, so I'm waiting. >-- >John > > > > ---------------------------- Michel SUCH TEAM OS/2 FRANCE ICQ # 51654489 **= Email 2 ==========================** Date: Sat, 9 Feb 2002 08:22:14 +0000 From: John Poltorak Subject: GNU OCR for OS/2 GOCR (GNU Optical Character Recognition) has been ported to OS/2. See:- http://home1.tiscalinet.de/fbakan/gocr-os2-035.htm -- John **= Email 3 ==========================** Date: Sat, 9 Feb 2002 09:06:12 +0000 From: John Poltorak Subject: unchecked.h v. unchecke.h EMXTREE contains unchecked.h whereas EMX/GCC has this file named as unchecke.h. I've also noticed several other files with longnames under EMXTREE. I presumed the longnamed variant is preferred... Isn't it likely to cause some problem using different names for the same file? -- John **= Email 4 ==========================** Date: Sat, 9 Feb 2002 09:17:51 +0000 From: John Poltorak Subject: Multimedia headers What is the source of the multimedia headers in EMXTREE? Some OS/2 toolkit? I guess it must be OK to distribute them... -- John **= Email 5 ==========================** Date: Sat, 9 Feb 2002 09:45:04 +0100 From: Holger Veit Subject: Re: ipc.h On Fri, Feb 08, 2002 at 08:40:16PM +0000, John Poltorak wrote: > > sys/ipc.h is much more recent in EMXTREE than EMX/GCC. I assume this is > correct. Where does it come from? > > Also what is the source of sys/sem.h and sys/shm.h ? This was an extension hack by me to get XShm running in XFree86/OS2. Discard that for now, SYSV IPC needs a complete rewrite. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 6 ==========================** Date: Sat, 09 Feb 2002 11:29:00 -0500 From: Henry Sobotka Subject: Re: Building Perl with gcc v3.0.2 John Poltorak wrote: > > Can anyone point out if there is anything obvious, which I may have overlooked? Don't know about the header barf but it may go away if you unset C_INCLUDE_PATH, since 3.0.2 can find its own way around in /emx. Beyond that, another problem in building Perl with 3.0.2 is that the multiPerl build system relies on old gcc's natural behavior of spitting out *.obj files with -Zomf and *.o without. With 3.0.2 you get *.o files with or without -Zomf unless you specify *.obj with the -o flag. 3.0.2's builtin -Dunix might also have effects. Checking sources for reliance on it is one of the first things you should do before building anything with 3.0.2. h~ **= Email 7 ==========================** Date: Sat, 09 Feb 2002 12:01:23 -0500 From: Henry Sobotka Subject: Re: Multimedia headers Holger Veit wrote: > > I have added some of the headers long ago for sound support in > my DOOM port. Admittedly, I have forgotten about them; they are not > strictly legal in EMXTREE. The belong to some 4.0 toolkit. They could probably replaced by mm4emx10. > Since LIBEMU should also have some sort of OS/2 support, or at least > needs it for the kernel DLL which heavily accesses Dos* calls, I am > wondering whether I can safely assume that every OS/2 programmer will > have access to one or another version of the toolkit. The 4.52 toolkit > is known to be part of eCS and MCP/ACP, so people who have updated > to one of these systems definitely have it, and subscribers to > DevCon can also download it. I tend to assume that programmers here > simply have it - I don't know yet whether "os2emx.h" which is no longer > fully up-to-date is sufficient as a replacement - and I am a bit > reluctant to reorganize the official headers just for the purpose > of having a "free" implementation: effectively, it is not own work > to lump all declarations from OS/2 toolkit files together somehow, > and everyone knows where the declarations come from. Not 100% safe as I can think of at least developer who's quite happy with Warp 4 + FP1x and feels the upgrades (eCS, MCP/ACP or DevCon pro) aren't worth the price. But I would say leave the onus of fixing os2emx.h on those who want a "free" implementation, and proceed on the assumption. h~ **= Email 8 ==========================** Date: Sat, 9 Feb 2002 13:14:31 -0500 From: Kees de LezenneCoulander Subject: Re: GLIBC csaba.raduly at sophos.com (Csaba Raduly) wrote: >>Not hogwash. The bottom line with any GPL (as opposed to BSD) license >>software is: 1) anything linked to it becomes GPL; 2) anything GPL'ed >>cannot be sold ^^^^^^^^^^^^^^ >Bzzzzzt ! Wrong: GPL'd code not only can, but *is* sold commercially. >Example: the GNU ADA translator (GNAT). GNAT as such is not sold. What you pay for is the support. The source code is available from an ftp site, together with binaries for the most common operating systems. It is true that the public versions run somewhat behind (usually half a year or so) the 'private' versions (i.e. those for supported customers). This annoys some people, but personally I do not mind waiting for the stable versions. The GNAT source code is now being merged into the main GCC version 3 tree, so that 'bleeding edge' snapshots can be obtained from the GCC CVS server. Kees de Lezenne Coulander -- C.M. de Lezenne Coulander Aircraft Development and Systems Engineering B.V. Hoofddorp, The Netherlands **= Email 9 ==========================** Date: Sat, 9 Feb 2002 14:10:44 +0000 From: John Poltorak Subject: gcc 3.0.2 and configure problem I thought I'd try gcc v3.0.2 with a configure script to see how well it worked. This is what I got when trying to build Flex:- configure.:1279: checking for gcc configure.:1295: found c:/emx.new/bin/gcc.exe configure.:1305: result: gcc configure.:1549: checking for C compiler version configure.:1552: gcc --version &5 3.0.2 configure.:1555: $? = 0 configure.:1557: gcc -v &5 Using builtin specs. Configured with: --enable-clh --enable-threads --disable-shared --enable-nls --without-included-gettext --prefix=/usr Thread model: os2 gcc version 3.0.2 configure.:1560: $? = 0 configure.:1562: gcc -V &5 gcc: argument to `-V' is missing configure.:1565: $? = 1 configure.:1591: checking for C compiler default output configure.:1594: gcc conftest.c >&5 as: unrecognized option `--traditional-format' configure.:1597: $? = 1 configure.: failed program was: #line 1568 "configure" #include "confdefs.h" #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ; return 0; } configure.:1624: error: C compiler cannot create executables Maybe this is a gcc installation problem... but I haven't managed to get any configure scripts to run yet. They all say:- error: C compiler cannot create executables What is causing the problem? Using gcc v2.8.1 works fine. Does v3.0.2 require some of the binaries which come with v2.8.1 or even PGCC v2.95.3? -- John **= Email 10 ==========================** Date: Sat, 9 Feb 2002 14:36:55 +0000 From: John Poltorak Subject: Re: gcc 3.0.2 and configure problem On Sat, Feb 09, 2002 at 02:10:44PM +0000, John Poltorak wrote: > > > I thought I'd try gcc v3.0.2 with a configure script to see how well it > worked. > > Maybe this is a gcc installation problem... but I haven't managed to get > any configure scripts to run yet. They all say:- > > error: C compiler cannot create executables > > > What is causing the problem? > > Using gcc v2.8.1 works fine. > > > Does v3.0.2 require some of the binaries which come with v2.8.1 or even > PGCC v2.95.3? Just to answer my own problem in case anyone else stumbles across the same thing. I needed to install the latest BINUTILS, specifically AS.EXE, not forgetting to add the required DLLs to my LIBPATH. It seems to have gone OK this time. Now let's see if I can build Perl v5.6.1 with gcc v3.0.2... -- John **= Email 11 ==========================** Date: Sat, 9 Feb 2002 14:59:00 +0000 From: John Poltorak Subject: Building Perl with gcc v3.0.2 Building Perl v5.6.1 with gcc v3.0.2 resulted in the following errors:- Updating GNUmakefile... make[1]: Leaving directory `/tmp/perl1/perl-5.6.1/x2p' Now you must run 'make'. If you compile perl5 on a different machine or from a different object directory, copy the Policy.sh file from this object directory to the new one before you run Configure -- this will help you with most of the policy defaults. `sh cflags libperl.lib malloc.obj` -Zdll malloc.c CCCMD = gcc -DPERL_CORE -c -Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -DEMX_BAD_SBRK -D_EMX_CRT_REV_= -fno-strict-aliasing -O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s In file included from malloc.c:240: perl.h:796: conflicting types for `sys_nerr' c:/emx/include/stdlib.h:148: previous declaration of `sys_nerr' perl.h:797: conflicting types for `sys_errlist' c:/emx/include/stdlib.h:147: previous declaration of `sys_errlist' In file included from perl.h:1639, from malloc.c:240: os2ish.h:412:19: operator 'EOL' has no left operand malloc.c: In function `Perl_sbrk': malloc.c:2083: `SYSTEM_ALLOC_ALIGNMENT' undeclared (first use in this function) malloc.c:2083: (Each undeclared identifier is reported only once malloc.c:2083: for each function it appears in.) make: *** [malloc.obj] Error 1 `sh cflags libperl.lib malloc.obj` -Zdll malloc.c CCCMD = gcc -DPERL_CORE -c -Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -DEMX_BAD_SBRK -D_EMX_CRT_REV_= -fno-strict-aliasing -O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s In file included from malloc.c:240: perl.h:796: conflicting types for `sys_nerr' c:/emx/include/stdlib.h:148: previous declaration of `sys_nerr' perl.h:797: conflicting types for `sys_errlist' c:/emx/include/stdlib.h:147: previous declaration of `sys_errlist' In file included from perl.h:1639, from malloc.c:240: os2ish.h:412:19: operator 'EOL' has no left operand malloc.c: In function `Perl_sbrk': malloc.c:2083: `SYSTEM_ALLOC_ALIGNMENT' undeclared (first use in this function) malloc.c:2083: (Each undeclared identifier is reported only once malloc.c:2083: for each function it appears in.) make: *** [malloc.obj] Error 1 Can anyone point out if there is anything obvious, which I may have overlooked? -- John **= Email 12 ==========================** Date: Sat, 09 Feb 2002 15:16:28 -0500 (EST) From: Ken Ames Subject: Re: Multimedia headers Hi, most of the mmpm headers are in the ddk which everyone knows is free for the register/download. The missing ones from a quick glance are midi.h mididll.h midios2.h miditype.h and minstall.h. Ken On Sat, 09 Feb 2002 16:41:08 +0100, Holger Veit wrote: >On Sat, Feb 09, 2002 at 09:17:51AM +0000, John Poltorak wrote: >> >> >> What is the source of the multimedia headers in EMXTREE? >> >> Some OS/2 toolkit? I guess it must be OK to distribute them... > >I have added some of the headers long ago for sound support in >my DOOM port. Admittedly, I have forgotten about them; they are not >strictly legal in EMXTREE. The belong to some 4.0 toolkit. > >Since LIBEMU should also have some sort of OS/2 support, or at least >needs it for the kernel DLL which heavily accesses Dos* calls, I am >wondering whether I can safely assume that every OS/2 programmer will >have access to one or another version of the toolkit. The 4.52 toolkit >is known to be part of eCS and MCP/ACP, so people who have updated >to one of these systems definitely have it, and subscribers to >DevCon can also download it. I tend to assume that programmers here >simply have it - I don't know yet whether "os2emx.h" which is no longer >fully up-to-date is sufficient as a replacement - and I am a bit >reluctant to reorganize the official headers just for the purpose >of having a "free" implementation: effectively, it is not own work >to lump all declarations from OS/2 toolkit files together somehow, >and everyone knows where the declarations come from. > >Opinions? > >Holger > >-- >Please update your tables to my new e-mail address: >holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > > **= Email 13 ==========================** Date: Sat, 9 Feb 2002 16:30:49 +0100 From: Holger Veit Subject: Re: unchecked.h v. unchecke.h On Sat, Feb 09, 2002 at 09:06:12AM +0000, John Poltorak wrote: > > > EMXTREE contains unchecked.h whereas EMX/GCC has this file named as > unchecke.h. I've also noticed several other files with longnames under > EMXTREE. I presumed the longnamed variant is preferred... > > Isn't it likely to cause some problem using different names for the same > file? There are scripts in EMX to extend header file names to its longname variant. The long names are usually the standard name (the one which is used in Unix). The short forms are for FAT 8.3 only. I am not sure, but I think gcc (rather cpp) contains code to clip header file names to 8.3 on FAT systems, so even if there is some #include "verylongname.h" in the source code, it will be found as "verylong.h" on FAT (it is possible that EMX also checks the .longname EA in such a case). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 14 ==========================** Date: Sat, 9 Feb 2002 16:41:08 +0100 From: Holger Veit Subject: Re: Multimedia headers On Sat, Feb 09, 2002 at 09:17:51AM +0000, John Poltorak wrote: > > > What is the source of the multimedia headers in EMXTREE? > > Some OS/2 toolkit? I guess it must be OK to distribute them... I have added some of the headers long ago for sound support in my DOOM port. Admittedly, I have forgotten about them; they are not strictly legal in EMXTREE. The belong to some 4.0 toolkit. Since LIBEMU should also have some sort of OS/2 support, or at least needs it for the kernel DLL which heavily accesses Dos* calls, I am wondering whether I can safely assume that every OS/2 programmer will have access to one or another version of the toolkit. The 4.52 toolkit is known to be part of eCS and MCP/ACP, so people who have updated to one of these systems definitely have it, and subscribers to DevCon can also download it. I tend to assume that programmers here simply have it - I don't know yet whether "os2emx.h" which is no longer fully up-to-date is sufficient as a replacement - and I am a bit reluctant to reorganize the official headers just for the purpose of having a "free" implementation: effectively, it is not own work to lump all declarations from OS/2 toolkit files together somehow, and everyone knows where the declarations come from. Opinions? 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: Sat, 9 Feb 2002 19:53:32 +0000 From: John Poltorak Subject: Re: Multimedia headers On Sat, Feb 09, 2002 at 12:01:23PM -0500, Henry Sobotka wrote: > Holger Veit wrote: > > > > I have added some of the headers long ago for sound support in > > my DOOM port. Admittedly, I have forgotten about them; they are not > > strictly legal in EMXTREE. The belong to some 4.0 toolkit. > > They could probably replaced by mm4emx10. The headers do look pretty similar to the one's in the toolkit. Maybe they could be updated to be even more similar... What happens if both are installed? I guess it's the sequence in the path which governs which is used > > Since LIBEMU should also have some sort of OS/2 support, or at least > > needs it for the kernel DLL which heavily accesses Dos* calls, I am > > wondering whether I can safely assume that every OS/2 programmer will > > have access to one or another version of the toolkit. The 4.52 toolkit > > is known to be part of eCS and MCP/ACP, so people who have updated > > to one of these systems definitely have it, and subscribers to > > DevCon can also download it. I tend to assume that programmers here > > simply have it - I don't know yet whether "os2emx.h" which is no longer > > fully up-to-date is sufficient as a replacement - and I am a bit > > reluctant to reorganize the official headers just for the purpose > > of having a "free" implementation: effectively, it is not own work > > to lump all declarations from OS/2 toolkit files together somehow, > > and everyone knows where the declarations come from. > > Not 100% safe as I can think of at least developer who's quite happy > with Warp 4 + FP1x and feels the upgrades (eCS, MCP/ACP or DevCon pro) > aren't worth the price. But I would say leave the onus of fixing > os2emx.h on those who want a "free" implementation, and proceed on the > assumption. What sort of licence is the toolkit released under? Is there any possibility of the toolkit being a free download from Devcon? There are some files which accessible through 'guest' access. Assuming the developer does have the toolkit, and it is used for building an app with gcc, then any installation of the EMX/GCC toolkit ought to be able to locate the OS/2 toolkit and append the relevant paths to the INCLUDE and LIBRARY paths. > h~ -- John **= Email 16 ==========================** Date: Sat, 9 Feb 2002 20:03:40 +0000 From: John Poltorak Subject: Re: unchecked.h v. unchecke.h On Sat, Feb 09, 2002 at 04:30:49PM +0100, Holger Veit wrote: > There are scripts in EMX to extend header file names to its longname > variant. How can anyone determine whether there was an original logname version which has been truncated by EMX? One thing I noticed under OBJC was nxconststr.h in EMXTREE, but NXConstS.h in EMX - the mixed case looked purposeful... Also noticed that list.h was in EMXTREE but missing from EMX/GCC... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 17 ==========================** Date: Sat, 09 Feb 2002 20:11:11 +0100 From: Andreas Buening Subject: make 3.79.1 and OS/2 "features" I have some question whether some workarounds that are provided within the make 3.79.1 source code are required for OS/2. 1) Is it possible to get an averaged system load? 2) FAT filesystems round file time to the nearest even second? (does this also apply to VFAT, FAT32?) 3) FAT filesystems can set file times up to 3 seconds into the future (only DJGPP, Win98+, WinNT)? 4) using _fnlwr() to change file names to lower case? 5) which additional suffixes do we need? They are needed for implicit and explicit rules, i.e. ------ .c.o: $(CC) -c ... foo.o: foo.c ------ works while ------ .c.obj: $(CC) -c ... foo.obj: foo.c ------ doesn't work as long as .obj isn't defined to be a suffix. my suggestion: .obj, .exe, .dll, .lib current default is: .out .a .ln .o .c .cc .C .cpp .p .f .F .r .y .l .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el 6) Should "gcc" be the native compiler instead of "cc"? 7) Which file systems do not change their "time of last change" for files/directories? 8) REXX support: is there anbody outside who uses this feature, or at least does anybody know anybody else who needs this feature? bye, Andreas **= Email 18 ==========================** Date: Sat, 9 Feb 2002 22:42:59 +0100 From: Holger Veit Subject: Re: unchecked.h v. unchecke.h On Sat, Feb 09, 2002 at 08:03:40PM +0000, John Poltorak wrote: > On Sat, Feb 09, 2002 at 04:30:49PM +0100, Holger Veit wrote: > > > There are scripts in EMX to extend header file names to its longname > > variant. > > How can anyone determine whether there was an original logname version > which has been truncated by EMX? /emx/include should contain the files long.cmd ,short.cmd, long.sed, longshrt.ls1, and longshrt.ls2 which do this conversion magic. Check their content. > One thing I noticed under OBJC was nxconststr.h in EMXTREE, but NXConstS.h > in EMX - the mixed case looked purposeful... Yes, some code (I suspect zip) lost the uppercase chars. OTOH, HPFS is not case sesnsitive. > Also noticed that list.h was in EMXTREE but missing from EMX/GCC... which list.h? One is for cpp, it belongs to regular stdc++ lib, the other one should be in objc. Both should be imported by some EMX package. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection)