From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 10 Feb 2002 04:14:49 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 131 ************************************************** Saturday 09 February 2002 Number 131 ************************************************** Subjects for today 1 Re: unchecked.h v. unchecke.h : John Poltorak 2 Re: Multimedia headers : John Poltorak 3 Re: GLIBC : John Poltorak 4 Re: Building Perl with gcc v3.0.2 : John Poltorak 5 Re: GLIBC : John Poltorak 6 Re: GLIBC : Michael Zolk 7 Re: Building Perl with gcc v3.0.2 : Henry Sobotka 8 Re: Multimedia headers : Ken Ames 9 GCC 3.0.2 problems : MS" **= Email 1 ==========================** Date: Sun, 10 Feb 2002 10:00:37 +0000 From: John Poltorak Subject: Re: unchecked.h v. unchecke.h On Sat, Feb 09, 2002 at 10:42:59PM +0100, Holger Veit wrote: > On Sat, Feb 09, 2002 at 08:03:40PM +0000, John Poltorak wrote: > /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. I had never even noticed those files! If I'm building a package to provide all the headers, I guess I can run long.cmd as part of the process and then omit *.sed, *.cmd, longshrt.* from the final package... Would there be any need to retain them under UnixOS/2? BTW what is check.cmd for? Maybe I should also run that... > > 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. Yes, but it just looks right when case matches the original and who knows what might be the consequences of not preserving case as in the difference between .s and .S files > > 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. The list.h for cpp originates in gppdev1.zip, but I can't identify the source for the one in objc. > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 2 ==========================** Date: Sun, 10 Feb 2002 10:34:23 +0000 From: John Poltorak Subject: Re: Multimedia headers On Sat, Feb 09, 2002 at 03:16:28PM -0500, Ken Ames wrote: > Hi, > most of the mmpm headers are in the ddk which everyone knows is free for the > register/download. I think this is an incorrect assumption. I would hope that the UnixOS/2 distro becomes established as part of many users OS/2 installation, ie. normal end users, not just developers, because I think OS/2 users ought to be able to install Open Source Software just as easily as people can on Linux. I don't imagine that every Linux user understands the ins and outs of configure scripts, but there is a good chance that they are successfull in installing software that they are not familiar with. As for getting any required Toolkits, I think there should be some way of prompting people to download them, possibly semi-automatically via a CURL script if that is possible. > The missing ones from a quick glance are midi.h mididll.h > midios2.h miditype.h and minstall.h. Are these used by gcc anywhere? > Ken -- John **= Email 3 ==========================** Date: Sun, 10 Feb 2002 10:38:09 +0000 From: John Poltorak Subject: Re: GLIBC On Sat, Feb 09, 2002 at 01:14:31PM -0500, Kees de LezenneCoulander wrote: > 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. Now that we appear to be uptodate with GNAT, it would be nice to see it merged with gcc v3 on OS/2 as well. > Kees de Lezenne Coulander > -- > C.M. de Lezenne Coulander > Aircraft Development and Systems Engineering B.V. > Hoofddorp, The Netherlands -- John **= Email 4 ==========================** Date: Sun, 10 Feb 2002 11:19:24 +0000 From: John Poltorak Subject: Re: Building Perl with gcc v3.0.2 On Sat, Feb 09, 2002 at 11:29:00AM -0500, Henry Sobotka wrote: > 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. I can't see how that would make any difference since I'm using the same headers in 3.0.2 as I used in 2.8.1, unless I have overlooked some requirement to upddate headers... How can I get conflicting types for `sys_nerr' which is declared in stdlib.h? There are also a number of these warnings:- cpp0.exe: warning: is shorter than expected I notice that 3.0.2 include a tradcpp0.exe and wonder if this one should be used instead although it's a smaller file. I don't really know what to make of the error msg... > h~ -- John **= Email 5 ==========================** Date: Sun, 10 Feb 2002 11:40:29 +0000 From: John Poltorak Subject: Re: GLIBC On Sun, Feb 10, 2002 at 12:05:21PM +0100, Michael Zolk wrote: > On Fri, Feb 08, 2002 at 10:28:18AM +0000, John Poltorak wrote: > > > > On Tue, Feb 05, 2002 at 08:19:07PM +0000, John Poltorak wrote: > > > > > > What should go in this 'development kit' ? > > > > I think such a package will be useful until LIBEMU is available > > because it helps to define a standard build environment and lets people > > get up and running quickly without having to trawl round the net looking > > for assorted headers and libs. > > > What I'd like to get is a list of headers and libs which people commonly > > include in INCLUDE and LIB, such as IlyaZ's db.lib, which are not part of > > the standard EMX/GCC distribution. > > IMO headers, static and import libraries that match the DLLs in the OS2LIBS > package should be included in this "libc-dev" package. I agree. Unfortunately I built REGEX.DLL from the GLIBC source, not realising how evil it was :-)... I'm not sure where to find BSD LIBC. > Michael > -- -- John **= Email 6 ==========================** Date: Sun, 10 Feb 2002 12:05:21 +0100 From: Michael Zolk Subject: Re: GLIBC On Fri, Feb 08, 2002 at 10:28:18AM +0000, John Poltorak wrote: > > On Tue, Feb 05, 2002 at 08:19:07PM +0000, John Poltorak wrote: > > > > What should go in this 'development kit' ? > I think such a package will be useful until LIBEMU is available > because it helps to define a standard build environment and lets people > get up and running quickly without having to trawl round the net looking > for assorted headers and libs. > What I'd like to get is a list of headers and libs which people commonly > include in INCLUDE and LIB, such as IlyaZ's db.lib, which are not part of > the standard EMX/GCC distribution. IMO headers, static and import libraries that match the DLLs in the OS2LIBS package should be included in this "libc-dev" package. Michael -- **= Email 7 ==========================** Date: Sun, 10 Feb 2002 13:43:36 -0500 From: Henry Sobotka Subject: Re: Building Perl with gcc v3.0.2 John Poltorak wrote: > > I can't see how that would make any difference since I'm using the same > headers in 3.0.2 as I used in 2.8.1, unless I have overlooked some > requirement to upddate headers... > > How can I get conflicting types for `sys_nerr' which is declared in > stdlib.h? Since I assume you haven't altered the Perl src, and we know the problem isn't inherent in the EMX headers because you've built Perl with 2.8.1, that leaves a clash between the EMX and 3.0.2 headers as the most likely origin. Unsetting C_INCLUDE_PATH ensures that 3.0.2 uses its builtin search order, which includes emx/include, without interference from the environment variable. My guess is that somewhere in the preprocessing of the headers, the __const__ qualifier is undefined in one case and not in the other. The best way to track down the problem is to add -save-temps to your CFLAGS, and look at the resulting *.ii file to see exactly what's happening. > There are also a number of these warnings:- > > cpp0.exe: warning: is shorter than expected I've seen those too, but IIRC it was with an earlier 3.x and went away with 3.0.2. There were problems with cpp0.exe and the pre-3.0.2 releases. There may be mention of them in Andy's docs. h~ **= Email 8 ==========================** Date: Sun, 10 Feb 2002 16:27:56 -0500 (EST) From: Ken Ames Subject: Re: Multimedia headers On Sun, 10 Feb 2002 10:34:23 +0000, John Poltorak wrote: >On Sat, Feb 09, 2002 at 03:16:28PM -0500, Ken Ames wrote: >> Hi, >> most of the mmpm headers are in the ddk which everyone knows is free for the >> register/download. > >I think this is an incorrect assumption. > This is not an incorrect assumtion, it is a fact. >I would hope that the UnixOS/2 distro becomes established as part of many >users OS/2 installation, ie. normal end users, not just developers, >because I think OS/2 users ought to be able to install Open Source >Software just as easily as people can on Linux. I don't imagine that every >Linux user understands the ins and outs of configure scripts, but there is >a good chance that they are successfull in installing software that they >are not familiar with. > >As for getting any required Toolkits, I think there should be some way of >prompting people to download them, possibly semi-automatically via a CURL >script if that is possible. > >> The missing ones from a quick glance are midi.h mididll.h >> midios2.h miditype.h and minstall.h. > >Are these used by gcc anywhere? gcc uses mmpm headers from it own contributed area. http://hobbes.nmsu.edu/pub/os2/dev/emx/contrib/mm4emx11.zip. Where they came from originally I do not know. > >> Ken > >-- >John > > Ken **= Email 9 ==========================** Date: Sun, 10 Feb 2002 21:56:21 +0100 (MEZ) From: "MS" Subject: GCC 3.0.2 problems Hello people, I have narrowed down the problem with building STLport on OS/2. STLport is including which in turn includes some other headers. I always get the errors: In file included from D:/DEVEL/C/EMX/include/g++-v3/bits/localefwd.h:43, from D:/DEVEL/C/EMX/include/g++-v3/bits/std_ios.h:43, from D:/DEVEL/C/EMX/include/g++-v3/bits/std_ostream.h:39, from D:/DEVEL/C/EMX/include/g++-v3/bits/std_iostream.h:40, from D:/DEVEL/C/EMX/include/g++-v3/iostream:31, from test.cpp:1: D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:59: `isalnum' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:60: `isalpha' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:61: `iscntrl' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:62: `isdigit' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:63: `isgraph' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:64: `islower' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:65: `isprint' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:66: `ispunct' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:67: `isspace' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:68: `isupper' not declared D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:69: `isxdigit' not declared The errors occurs when I am trying to compile STLport as well as a simple test program which includes cwchar but does not make actual use of it. The search path is as follows: #include <...> search starts here: D:/DEVEL/C/EMX/lib/gcc-lib/i386-pc-os2_emx/3.0.2/include D:/DEVEL/C/EMX/include D:/DEVEL/C/EMX/include/g++-v3 D:/DEVEL/C/EMX/include/g++-v3/i386-pc-os2_emx D:/DEVEL/C/EMX/include/g++-v3/backward End of search list. Again, is this a bug in gcc3.0.2? Regards, Martin Schafföner