Date: Mon, 29 Mar 2004 00:20:09 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 328 ************************************************** Sunday 28 March 2004 Number 328 ************************************************** Subjects for today 1 SED one-liners : John Poltorak 2 Re: SED one-liners : Steven Levine" 3 Re: Building subversion (was /vfs?) : Stefan Neis 4 Re: Building subversion (was /vfs?) : Stefan Neis 5 Re: Crosscompiling : Stefan Neis 6 Re: Crosscompiling : Stefan Neis 7 Re: Makefile - default target : Stefan Neis 8 Embedded paths in Perl : John Poltorak 9 Re: Building subversion (was /vfs?) : John Poltorak 10 Re: Makefile - default target : John Poltorak 11 Re: Building UNZIP using Posix/2 : Stefan Neis 12 Re: Building UNZIP using Posix/2 : Stefan Neis 13 Re: Building subversion (was /vfs?) : Stefan Neis 14 Re: Embedded paths in Perl : Henry Sobotka 15 Re: Embedded paths in Perl : John Poltorak 16 Re: Building subversion (was /vfs?) : John Poltorak 17 Re: Embedded paths in Perl : Henry Sobotka 18 Re: Crosscompiling : Steve Wendt" 19 Re: Crosscompiling : Steve Wendt" 20 Re: source control : Steve Wendt" 21 Re: Crosscompiling : Dave and Natalie" 22 Re: Embedded paths in Perl : Dave and Natalie" 23 Re: Embedded paths in Perl : John Poltorak 24 Re: Building UNZIP using Posix/2 : John Poltorak 25 Re: Building Make v3.79.1 : John Poltorak 26 Re: Crosscompiling : Thomas Dickey 27 JPEG configure : John Poltorak 28 Re: Crosscompiling : Stefan Neis 29 Re: JPEG configure : Stefan Neis 30 Re: Building Make v3.79.1 : Stefan Neis 31 Re: Building UNZIP using Posix/2 : Stefan Neis **= Email 1 ==========================** Date: Sat, 27 Mar 2004 13:20:39 +0000 From: John Poltorak Subject: SED one-liners If anyone wants to get up to speed with SED, I'd suggest having a look around the maintainer's home page here:- http://www.student.northpark.edu/pemente/sed/ .... and I'd recommend learning some of the handy SED one-liners in:- http://www.student.northpark.edu/pemente/sed/sed1line.txt It can often save you the trouble of knocking together a short REXX script for processing a text file if you can use a simple SED script. -- John **= Email 2 ==========================** Date: Sat, 27 Mar 2004 09:21:42 -0800 From: "Steven Levine" Subject: Re: SED one-liners In <20040327132039.D44505 at warpix.org>, on 03/27/04 at 01:20 PM, John Poltorak said: >It can often save you the trouble of knocking together a short REXX >script for processing a text file if you can use a simple SED script. Or awk or perl. :-) Almost any of these is less verbose than the equivalent REXX script. The big benefit of REXX (or at least classic REXX) on OS/2 is that everybody has it. The other benefit, which is not used as often as it should be, it that REXX can be embedded in the app as the native scripting language. When used this way REXX usually has better performance than the other options becuase there's no EXE to load. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 27 Mar 2004 18:50:33 +0100 (CET) From: Stefan Neis Subject: Re: Building subversion (was /vfs?) On Thu, 25 Mar 2004, John Poltorak wrote: > /* Fill space with random characters */ > while (*trv == 'X') { > randnum = arc4random() % (sizeof(padchar) - 1); > *trv-- = padchar[randnum]; > } In view of stdlib.h's _STD_INL unsigned int arc4random(void) {return _arc4random();} that should be OK > #if defined(SVR4) || defined(WIN32) || defined(NETWARE) /* WIN32, NETWARE, SVR4 shouldn't be relevant, AFAICS. */ > #ifdef SVR4 > #if HAVE_INTTYPES_H > #include > #endif > #endif > #define arc4random() rand() > #define seedrandom(a) srand(a) > #else /* so this is the case that's relevant for us ... > #if APR_HAVE_STDINT_H > #include > #endif > #define arc4random() random() Is that valid syntax at all? Maybe try to simple remove that line (and the following one) for a quick test? as arc4random is a function defined by Posix/2, those defines shouldn't be needed anyway... > #define seedrandom(a) srandom(a) > #endif > extern long _random(void); > extern unsigned int _arc4random(void); > extern void _arc4random_stir(void); > extern void _arc4random_addrandom(unsigned char*,int); Somewhat later, there's even more... (e.g. the line I quoted above ...) Regards, Stefan **= Email 4 ==========================** Date: Sat, 27 Mar 2004 18:56:27 +0100 (CET) From: Stefan Neis Subject: Re: Building subversion (was /vfs?) On Fri, 26 Mar 2004, Johannes Fahrenkrug wrote: > That is true... well, for now the point is to build it at all. Then we > could at least release a binary until it works with the build command. > Because there is not a single subversion client out there for OS/2... BTW, why do you need it? I.e. which interesting project is using subversion? We (i.e. the company where I'm working) have the idea to switch from CVS and Sourcesafe (currently we are using both in parallerel for "historical reasons" ;-) )to SubVersion, if there's an "interesting" project that's already using it, that would be helpful in forming an opinion ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Sat, 27 Mar 2004 18:58:59 +0100 (CET) From: Stefan Neis Subject: Re: Crosscompiling On Fri, 26 Mar 2004, Steve Wendt wrote: > Cross-compiling with GCC is a nightmare for supported platforms, without > even mentioning OS/2. When the Linux port of OpenWatcom has been > completed, then you might want to try cross-compiling. ;) Only, you probably don't want to port Unix software to OpenWatcom . :-( Especially it's pre-ANSI C++ "support" is a real problem. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Sat, 27 Mar 2004 19:02:57 +0100 (CET) From: Stefan Neis Subject: Re: Crosscompiling On Sat, 27 Mar 2004, John Poltorak wrote: > Is there any chance of OpenWatcom being able to build major open source > apps like Perl in the not too distant future, if ever? Ask again when OpenWatcom has autoconf support and autoconf has OpenWatcom support. With SciTech mainly being interested in using the compiler to compile their own internal projects with their own make system, this might take a while, though. Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 7 ==========================** Date: Sat, 27 Mar 2004 19:13:06 +0100 (CET) From: Stefan Neis Subject: Re: Makefile - default target On Sat, 27 Mar 2004, John Poltorak wrote: > dependency. But since many apps are not dependent on other apps, I didn't > want to include them specifically in the Makefile but have a default rule > which would catch all targets not mentioned. It seems I can't do that. Pattern rules might be able to help, e.g. %.exe: % cd somewhere; build $< %.lib: % cd somewhere; build $< Now "make less.exe" will execute "cd somewhere; build less" if dummy-file less is newer than dummy file less.exe", similar for libs. And for specific apps, you could override it (or even just add a dependency) like so: dialog.exe: dialog ncurses.lib Just a rough idea, those dummy files I'm currently requiring are definitely not nice, but it should be possible to cope without real files at least for the default case... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 8 ==========================** Date: Sat, 27 Mar 2004 19:25:18 +0000 From: John Poltorak Subject: Embedded paths in Perl I noticed today that I can't build Autoconf if I use Perl which was built on another system. The reason for this appears to be that the Perl dll includes an embedded path for sh.exe which just happened to be u:/usr/bin/sh.exe on the system where Perl was built, but this path does not exist on the system where Autoconf is being built. I had never been aware of this problem previously. Is there any way to get Perl to build the DLL with just the filename or even without the drive letter being included? The same problem occurs when building automake. -- John **= Email 9 ==========================** Date: Sat, 27 Mar 2004 19:33:53 +0000 From: John Poltorak Subject: Re: Building subversion (was /vfs?) On Sat, Mar 27, 2004 at 06:50:33PM +0100, Stefan Neis wrote: > In view of stdlib.h's > _STD_INL unsigned int arc4random(void) {return _arc4random();} > that should be OK > > > #if defined(SVR4) || defined(WIN32) || defined(NETWARE) > /* WIN32, NETWARE, SVR4 shouldn't be relevant, AFAICS. */ > > #ifdef SVR4 > > #if HAVE_INTTYPES_H > > #include > > #endif > > #endif > > #define arc4random() rand() > > #define seedrandom(a) srand(a) > > #else > /* so this is the case that's relevant for us ... > > #if APR_HAVE_STDINT_H > > #include > > #endif > > #define arc4random() random() > Is that valid syntax at all? Maybe try to simple remove that line > (and the following one) for a quick test? as arc4random is a function > defined by Posix/2, those defines shouldn't be needed anyway... > > #define seedrandom(a) srandom(a) > > #endif > > > extern long _random(void); > > extern unsigned int _arc4random(void); > > extern void _arc4random_stir(void); > > extern void _arc4random_addrandom(unsigned char*,int); > > Somewhat later, there's even more... (e.g. the line I quoted above ...) I'm not really clear about which line in which file you are suggesting changing. If you give me a patch I will try it out. > Regards, > Stefan -- John **= Email 10 ==========================** Date: Sat, 27 Mar 2004 19:53:39 +0000 From: John Poltorak Subject: Re: Makefile - default target On Sat, Mar 27, 2004 at 07:13:06PM +0100, Stefan Neis wrote: > On Sat, 27 Mar 2004, John Poltorak wrote: > > > dependency. But since many apps are not dependent on other apps, I didn't > > want to include them specifically in the Makefile but have a default rule > > which would catch all targets not mentioned. It seems I can't do that. > > Pattern rules might be able to help, e.g. > > %.exe: % > cd somewhere; build $< > %.lib: % > cd somewhere; build $< > > Now "make less.exe" will execute "cd somewhere; build less" if dummy-file > less is newer than dummy file less.exe", similar for libs. > And for specific apps, you could override it (or even just add a > dependency) like so: > dialog.exe: dialog ncurses.lib > > Just a rough idea, those dummy files I'm currently requiring are > definitely not nice, but it should be possible to cope without real > files at least for the default case... Thanks for the suggestion... I can use something like: mailman.pkg: check mailman dependencies *.pkg: - for all specific pkgs %.pkg: build $< I'll just add a front end to add on the .pkg extension. Now I need to work out how to specify dependicies... If, for instance, I want to build mailman, and a prerequisite is the existance of /usr/bin/python.exe, how would I write that? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 11 ==========================** Date: Sat, 27 Mar 2004 21:39:05 +0100 (CET) From: Stefan Neis Subject: Re: Building UNZIP using Posix/2 On Thu, 25 Mar 2004, John Poltorak wrote: > Here is the relevant code:- Well, some comments... > #if (defined(BSD) || defined(MTS) || defined(__GO32__)) Bad luck, Posix/2 _does_ define BSD, so we now get to compile that code we really didn't want to touch (and which simply is ignored by EMX, which explains why plain EMX does work) ... > if ((tm = localtime(&m_time)) != (struct tm *)NULL) > /* line 1743 ====> */ m_time -= tm->tm_gmtoff; /* sec. EAST of GMT: subtr. */ .... and in addition we get confronted with "struct tm" which needs to be defined in a way compatible with EMX if Posix/2 is supposed to work in combination with EMX at all, so we simply don't have the member tm_gmtoff, although we should have it, if we claim to be BSD compatible. No real way out except for reordering the #defines in the source code, so we still get what we want if _both_ EMX and BSD are defined. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 12 ==========================** Date: Sat, 27 Mar 2004 21:39:05 +0100 (CET) From: Stefan Neis Subject: Re: Building UNZIP using Posix/2 On Thu, 25 Mar 2004, John Poltorak wrote: > Here is the relevant code:- Well, some comments... > #if (defined(BSD) || defined(MTS) || defined(__GO32__)) Bad luck, Posix/2 _does_ define BSD, so we now get to compile that code we really didn't want to touch (and which simply is ignored by EMX, which explains why plain EMX does work) ... > if ((tm = localtime(&m_time)) != (struct tm *)NULL) > /* line 1743 ====> */ m_time -= tm->tm_gmtoff; /* sec. EAST of GMT: subtr. */ .... and in addition we get confronted with "struct tm" which needs to be defined in a way compatible with EMX if Posix/2 is supposed to work in combination with EMX at all, so we simply don't have the member tm_gmtoff, although we should have it, if we claim to be BSD compatible. No real way out except for reordering the #defines in the source code, so we still get what we want if _both_ EMX and BSD are defined. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 13 ==========================** Date: Sat, 27 Mar 2004 21:55:03 +0100 (CET) From: Stefan Neis Subject: Re: Building subversion (was /vfs?) On Sat, 27 Mar 2004, John Poltorak wrote: ------- snipp ------ > > > #if defined(SVR4) || defined(WIN32) || defined(NETWARE) > > /* WIN32, NETWARE, SVR4 shouldn't be relevant, AFAICS. */ > > > #ifdef SVR4 > > > #if HAVE_INTTYPES_H > > > #include > > > #endif > > > #endif > > > #define arc4random() rand() > > > #define seedrandom(a) srand(a) > > > #else > > /* so this is the case that's relevant for us ... > > > #if APR_HAVE_STDINT_H > > > #include > > > #endif > > > #define arc4random() random() > > Is that valid syntax at all? Maybe try to simple remove that line > > (and the following one) for a quick test? as arc4random is a function > > defined by Posix/2, those defines shouldn't be needed anyway... > > > #define seedrandom(a) srandom(a) > > > #endif ---- snipp ---- > I'm not really clear about which line in which file you are suggesting > changing. This part between the two lines "----snipp----" is something _you_ quoted from some file, I have no idea from which one, but had the impression it's the one where subversion build errors out. I've been "blindly" commenting the code you quoted, without actually looking up the file ... Stefan **= Email 14 ==========================** Date: Sat, 27 Mar 2004 16:19:30 -0500 From: Henry Sobotka Subject: Re: Embedded paths in Perl John Poltorak wrote: > > I noticed today that I can't build Autoconf if I use Perl which was built > on another system. The reason for this appears to be that the Perl dll > includes an embedded path for sh.exe which just happened to be > u:/usr/bin/sh.exe on the system where Perl was built, but this path does > not exist on the system where Autoconf is being built. I had never been > aware of this problem previously. Is there any way to get Perl to build > the DLL with just the filename or even without the drive letter being > included? > > The same problem occurs when building automake. You might try setting PERL_SH_DIR to point to the directory containing sh.exe. You should also check Config.PM for instances of u: if you haven't already. h~ -- Free software, free minds. **= Email 15 ==========================** Date: Sat, 27 Mar 2004 21:31:26 +0000 From: John Poltorak Subject: Re: Embedded paths in Perl On Sat, Mar 27, 2004 at 04:19:30PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > I noticed today that I can't build Autoconf if I use Perl which was built > > on another system. The reason for this appears to be that the Perl dll > > includes an embedded path for sh.exe which just happened to be > > u:/usr/bin/sh.exe on the system where Perl was built, but this path does > > not exist on the system where Autoconf is being built. I had never been > > aware of this problem previously. Is there any way to get Perl to build > > the DLL with just the filename or even without the drive letter being > > included? > > > > The same problem occurs when building automake. > > You might try setting PERL_SH_DIR to point to the directory containing > sh.exe. Is this something which can be set when building Perl or when running it? If I can build it without a drive letter that wouldn't be too bad - I'm not keen on having to set variables unnecessarily. > You should also check Config.PM for instances of u: if you > haven't already. Perl was build on the u: drive and u:/usr/bin/sh.exe was valid at the time it was built, but it isn't anywhere else. > h~ > -- > Free software, free minds. -- John **= Email 16 ==========================** Date: Sat, 27 Mar 2004 21:39:48 +0000 From: John Poltorak Subject: Re: Building subversion (was /vfs?) On Sat, Mar 27, 2004 at 09:55:03PM +0100, Stefan Neis wrote: > On Sat, 27 Mar 2004, John Poltorak wrote: > > ------- snipp ------ > > > > #if defined(SVR4) || defined(WIN32) || defined(NETWARE) > > > /* WIN32, NETWARE, SVR4 shouldn't be relevant, AFAICS. */ > > > > #ifdef SVR4 > > > > #if HAVE_INTTYPES_H > > > > #include > > > > #endif > > > > #endif > > > > #define arc4random() rand() > > > > #define seedrandom(a) srand(a) > > > > #else > > > /* so this is the case that's relevant for us ... > > > > #if APR_HAVE_STDINT_H > > > > #include > > > > #endif > > > > #define arc4random() random() > > > Is that valid syntax at all? Maybe try to simple remove that line > > > (and the following one) for a quick test? as arc4random is a function > > > defined by Posix/2, those defines shouldn't be needed anyway... > > > > #define seedrandom(a) srandom(a) > > > > #endif > ---- snipp ---- > > > > I'm not really clear about which line in which file you are suggesting > > changing. > > This part between the two lines "----snipp----" is something _you_ quoted > from some file, I have no idea from which one, but had the impression it's > the one where subversion build errors out. It's from subversion - apr/file_io/unix/mktemp.c > I've been "blindly" commenting the code you quoted, without actually > looking up the file ... So you are suggesting removing this single line:- ? #define arc4random() random() > Stefan -- John **= Email 17 ==========================** Date: Sat, 27 Mar 2004 17:11:59 -0500 From: Henry Sobotka Subject: Re: Embedded paths in Perl John Poltorak wrote: > > Is this something which can be set when building Perl or when running it? Runtime. Perl uses it while firing up to look for a sh.exe on the system and I would expect it to override the hardcoded path from the original build. h~ -- Free software, free minds. **= Email 18 ==========================** Date: Sat, 27 Mar 2004 14:43:42 -0800 (PST) From: "Steve Wendt" Subject: Re: Crosscompiling On Sat, 27 Mar 2004 09:57:33 +0000, John Poltorak wrote: >Is there any chance of OpenWatcom being able to build major open source >apps like Perl in the not too distant future, if ever? It's an open source project, so it will do whatever anyone gets it to do... I understand there is now an "owcc," which is a frontend like gcc to be used by standard Unix makefiles. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 19 ==========================** Date: Sat, 27 Mar 2004 14:44:35 -0800 (PST) From: "Steve Wendt" Subject: Re: Crosscompiling On Sat, 27 Mar 2004 18:58:59 +0100 (CET), Stefan Neis wrote: >Only, you probably don't want to port Unix software to OpenWatcom . :-( >Especially it's pre-ANSI C++ "support" is a real problem. Most Unix software is written in C. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 20 ==========================** Date: Sat, 27 Mar 2004 14:51:10 -0800 (PST) From: "Steve Wendt" Subject: Re: source control On Sat, 27 Mar 2004 18:56:27 +0100 (CET), Stefan Neis wrote: >We (i.e. the company where I'm working) have the idea >to switch from CVS and Sourcesafe (currently we are using both in >parallerel for "historical reasons" ;-) )to SubVersion, if there's an If you're shopping around, Perforce is really nice. It's not free, though, except for open source projects. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 21 ==========================** Date: Sat, 27 Mar 2004 19:10:18 -0800 From: "Dave and Natalie" Subject: Re: Crosscompiling On Sat, 27 Mar 2004 14:44:35 -0800 (PST), Steve Wendt wrote: >On Sat, 27 Mar 2004 18:58:59 +0100 (CET), Stefan Neis wrote: > >>Only, you probably don't want to port Unix software to OpenWatcom . :-( >>Especially it's pre-ANSI C++ "support" is a real problem. > >Most Unix software is written in C. I'm coming across more and more written in C++, most of which need a newer GCC. These are mostly X apps Dave **= Email 22 ==========================** Date: Sat, 27 Mar 2004 22:54:59 -0800 From: "Dave and Natalie" Subject: Re: Embedded paths in Perl On Sat, 27 Mar 2004 21:31:26 +0000, John Poltorak wrote: > >If I can build it without a drive letter that wouldn't be too bad - I'm >not keen on having to set variables unnecessarily. Others may have multiple partitions and want to run Perl from them. Sometimes variables are the best solution > >> You should also check Config.PM for instances of u: if you >> haven't already. > >Perl was build on the u: drive and u:/usr/bin/sh.exe was valid at the time >it was built, but it isn't anywhere else. Could always have a script that updates drive letters in /usr/lib/perl5.8.3/os2/Config.PM and eliminate some of them. Dave **= Email 23 ==========================** Date: Sun, 28 Mar 2004 10:22:40 +0000 From: John Poltorak Subject: Re: Embedded paths in Perl On Sat, Mar 27, 2004 at 10:54:59PM -0800, Dave and Natalie wrote: > On Sat, 27 Mar 2004 21:31:26 +0000, John Poltorak wrote: > > > > >If I can build it without a drive letter that wouldn't be too bad - I'm > >not keen on having to set variables unnecessarily. > > Others may have multiple partitions and want to run Perl from them. I have a number of machines with multiple partitions and often use network drives as well which complicates things no end. > Sometimes variables are the best solution I guess so, but I liked Holger's original idea of creating a new EMX runtime which was able to make use of a user supplied %UNIXROOT% variable which could substitute or apply drive letters at runtime. > >> You should also check Config.PM for instances of u: if you > >> haven't already. > > > >Perl was build on the u: drive and u:/usr/bin/sh.exe was valid at the time > >it was built, but it isn't anywhere else. > > Could always have a script that updates drive letters in /usr/lib/perl5.8.3/os2/Config.PM and eliminate some of them. Can you give me an example? > Dave -- John **= Email 24 ==========================** Date: Sun, 28 Mar 2004 10:37:08 +0000 From: John Poltorak Subject: Re: Building UNZIP using Posix/2 On Sat, Mar 27, 2004 at 09:39:05PM +0100, Stefan Neis wrote: > On Thu, 25 Mar 2004, John Poltorak wrote: > > > Here is the relevant code:- > > Well, some comments... > > > #if (defined(BSD) || defined(MTS) || defined(__GO32__)) > > Bad luck, Posix/2 _does_ define BSD, so we now get to compile that code > we really didn't want to touch (and which simply is ignored by EMX, which > explains why plain EMX does work) ... I'm so glad that you can find your way through this maze :-)... > > if ((tm = localtime(&m_time)) != (struct tm *)NULL) > > /* line 1743 ====> */ m_time -= tm->tm_gmtoff; /* sec. EAST of GMT: subtr. */ > > ... and in addition we get confronted with "struct tm" which needs to be > defined in a way compatible with EMX if Posix/2 is supposed to work in > combination with EMX at all, so we simply don't have the member tm_gmtoff, > although we should have it, if we claim to be BSD compatible. No real way > out except for reordering the #defines in the source code, so we still get > what we want if _both_ EMX and BSD are defined. So if tm_gmtoff is added to Posix/2 will that sort out the problem? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 25 ==========================** Date: Sun, 28 Mar 2004 12:41:07 +0000 From: John Poltorak Subject: Re: Building Make v3.79.1 On Sat, Mar 27, 2004 at 11:57:18AM +0000, John Poltorak wrote: > > Is anyone able to build Make v3.79.1 from source? > > There is a source package on Hobbes:- > > http://hobbes.nmsu.edu/pub/os2/dev/util/make-3_79_1.zip > > I've tried to follow the instructions but haven't quite mastered it. > > > Maybe someone else has... I've now managed it on one system, but can't reproduce it on another. As far as I can make out the two environments look the same, but obviously something is different. One thing about the instance where it does work is that there is a presence of a .deps directory with lots of *.P files. This doesn't get created when it fails. Anyone know anything about a .deps directory or what creates it? -- John **= Email 26 ==========================** Date: Sun, 28 Mar 2004 06:44:55 -0500 (EST) From: Thomas Dickey Subject: Re: Crosscompiling On Sat, 27 Mar 2004, Dave and Natalie wrote: > On Sat, 27 Mar 2004 14:44:35 -0800 (PST), Steve Wendt wrote: > > >On Sat, 27 Mar 2004 18:58:59 +0100 (CET), Stefan Neis wrote: > > > >>Only, you probably don't want to port Unix software to OpenWatcom . :-( > >>Especially it's pre-ANSI C++ "support" is a real problem. > > > >Most Unix software is written in C. > > I'm coming across more and more written in C++, most of which need a > newer GCC. These are mostly X apps It occurs to me that you might be referring to things that rely on g++ (and it is not unusual to see those also relying on specific features of GNU c/c++ that are not standard). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 27 ==========================** Date: Sun, 28 Mar 2004 14:28:35 +0000 From: John Poltorak Subject: JPEG configure Looking through the source for jpeg6b, it comes with a configure script which says it has been automatically generated by autoconf (2.12) but there is no configure.in supplied? This means I can't rebuild one to check for options like executable suffix, so if CFLAGS is set to include -Zomf, configure fails. Can anyone suggest a solution? I'd prefer to generate my own Makefile rather than one with hard coded paths, that is why I don't really want to use a specific Makefile. -- John **= Email 28 ==========================** Date: Sun, 28 Mar 2004 15:36:30 +0200 (CEST) From: Stefan Neis Subject: Re: Crosscompiling On Sun, 28 Mar 2004, Thomas Dickey wrote: > > I'm coming across more and more written in C++, most of which need a > > newer GCC. These are mostly X apps > > It occurs to me that you might be referring to things that rely on g++ > (and it is not unusual to see those also relying on specific features > of GNU c/c++ that are not standard). Actually, it's sufficient for software to use namespaces or member templates which are perfectly valid ISO C++ to make gcc-2.8 (or OpenWatcom) unusable for compilation. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 29 ==========================** Date: Sun, 28 Mar 2004 15:39:22 +0200 (CEST) From: Stefan Neis Subject: Re: JPEG configure On Sun, 28 Mar 2004, John Poltorak wrote: > which says it has been automatically generated by autoconf (2.12) but > there is no configure.in supplied? This means I can't rebuild one to check > for options like executable suffix, so if CFLAGS is set to include -Zomf, > configure fails. > > Can anyone suggest a solution? Writing to the maintainers and asking for configure.in? Preferably an updated one, which works with autoconf-2.5x ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 30 ==========================** Date: Sun, 28 Mar 2004 15:43:48 +0200 (CEST) From: Stefan Neis Subject: Re: Building Make v3.79.1 On Sun, 28 Mar 2004, John Poltorak wrote: > Anyone know anything about a .deps directory or what creates it? Normally, you manually specify, which files a particular target depends on, however for large projects it's tiresome to manually add dependencies of C(++) files on header files that are included, so gcc has a special switch which makes it generate those dependencies (based on include directives) in a format suitable for inclusion by make. Those files are often put into a .deps subdirectory. HTH, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 31 ==========================** Date: Sun, 28 Mar 2004 15:55:10 +0200 (CEST) From: Stefan Neis Subject: Re: Building UNZIP using Posix/2 On Sun, 28 Mar 2004, John Poltorak wrote: > So if tm_gmtoff is added to Posix/2 will that sort out the problem? No. I would cleanly compile, but since Posix/2 is just an add-on for EMX, relying on EMX for the low level work, tm_gmtoff (unknown to EMX) never would get a reasonable value. Also, it would cause endless complications with using "struct tm" since EMX and Posix/2 would make different assumptions on it's size, so we'd have to reimplement all the functions involving "struct tm" - that would sort out the problem, but it's more than I currently can find time for... Stefan