Date: Tue, 11 May 2004 00:04:23 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 375 ************************************************** Monday 10 May 2004 Number 375 ************************************************** Subjects for today 1 Re: os2unix.cmd : John Poltorak 2 Re: distcc : Stefan.Neis at t-online.de 3 Re: os2unix.cmd : IanM" 4 Bind : IanM" 5 Re: zlib.def : Dave Yeo" 6 Re: Linking with external regex.lib : Stefan.Neis at t-online.de 7 Re: Bind : John Poltorak 8 Re: distcc : John Poltorak 9 Re: zlib.def : John Poltorak 10 Re: zlib.def : Dave Yeo" 11 Re: zlib.def : John Poltorak 12 Re: distcc : Stefan.Neis at t-online.de 13 Re: zlib.def : Stefan.Neis at t-online.de 14 Re: zlib.def : John Poltorak 15 Format of DEF files : John Poltorak 16 Re: Format of DEF files : Sebastian Wittmeier" 17 Re: zlib.def : Dave Yeo" 18 Re: distcc : Dave Yeo" 19 Re: distcc : John Poltorak 20 ZLIB & minigzip : John Poltorak 21 Re: zlib.def : John Poltorak 22 Re: OOO_1_1_1 : Sebastian Wittmeier" 23 Re: OOO_1_1_1 : John Poltorak 24 Perl - $OSNAME : John Poltorak 25 Re: Perl - $OSNAME : Sebastian Wittmeier" 26 Re: Perl - $OSNAME : John Poltorak 27 Re: Perl - $OSNAME : Sebastian Wittmeier" 28 NETPBM : John Poltorak 29 Re: zlib.def : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Sun, 9 May 2004 14:52:27 +0100 From: John Poltorak Subject: Re: os2unix.cmd On Sun, May 09, 2004 at 11:35:22PM +1000, IanM wrote: > Hi John > > I think you will also have to back date the autoconf files as well if you > do want it to work, as well as I think I had to use a particular version of > make. I thought the whole point of os2unix.cmd was to convert the distributed configure script into an OS/2 friendly one without the need to run autoconf... > Cheers > IanM > http://www.os2site.com/ > > "Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us." CalviN and HobbEs -- John **= Email 2 ==========================** Date: Sun, 9 May 2004 16:47:02 +0100 From: Stefan.Neis at t-online.de Subject: Re: distcc Hi. > > One thing IIRC you > > said you used -Zomf. This won't work as distcc forks and OMF builds do not allow forking > > I used -Zomf to make it compile, which it does as a result. I'm not sure > of the implications of fork not working. Does it mean the app won't work > at all? Exactly. Probably just the behaviour you currently observe... > What does it do instead of fork? Good question. Nothing useful, in any case. I wonder, why there even is (apparently) a stub for it, getting a linker error for trying to compile something using fork with -Zomf would be more helpful, IMHO. Regards, Stefan **= Email 3 ==========================** Date: Mon, 10 May 2004 02:12:15 +1000 (EST) From: "IanM" Subject: Re: os2unix.cmd Hi John > I thought the whole point of os2unix.cmd was to convert the distributed > configure script into an OS/2 friendly one without the need to run > autoconf... I'm sure I had to run auto something, not sure, we are talking about a long time ago but yes what your saying does sound familiar. I left that cmd file a long time ago, think it was a case of upgraded one utility and broke it, couldnt make it work again and never went back to it. Cheers IanM http://www.os2site.com/ Once you pull the pin, mister handgrenade is no longer your friend... **= Email 4 ==========================** Date: Mon, 10 May 2004 02:27:15 +1000 (EST) From: "IanM" Subject: Bind Sidenote, I've got back on the bind case with v8.4.4 which compiles a lot further out of the box with the latest GCC, it runs but I cant make it bind to a single IP address, wants to bind to every IP address, and recursion doesnt turn off. The IPv6 code in it though has to be turned off, obviously. I'm comiling it using the AIX gcc makefile and includes, with some replacement .h files from the OS/2 tcp/ip toolkit. Seems to get a lot further that using the earlier BSD POSIX stuff which caused me no end of grief. Just need to find the time to really site down and finish it, the last couple of years I seem to lack the staying power that programming requires. Cheers IanM http://www.os2site.com/ Santa's elves are just a bunch of subordinate Clauses. **= Email 5 ==========================** Date: Sun, 09 May 2004 09:53:45 -0800 From: "Dave Yeo" Subject: Re: zlib.def --_=_=_=IMA.BOUNDARY.HXG99L138764=_=_=_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 9 May 2004 12:11:03 +0100, John Poltorak wrote: > >Many thanks for that, it builds z.dll OK, but I also get this error msg:- > >gcc -O2 -m486 -D__ST_MT_ERRNO__ -Zmtd -Zomf -I. -c -o example.o example.c >gcc -O2 -m486 -D__ST_MT_ERRNO__ -Zmtd -Zomf -I. -o example.exe example.o exedefault.def -s -L. -lz -Zbin-files >gcc: exedefault.def: No such file or directory >make: *** [example.exe] Error 1 > > >I can't work out what exedefault.def is supposed to be or where I can find >it. Woops, here it is. > >As for the Makefile, how would it need to be changed to turn it into a >Makefile.in? If possible, I would like to build ZLIB using the supplied >configure script, and that might work with some changes to the Makefile.in >which comes included. It could be done, though you'd have to call something like make z.dll and it would break compatibility with Linux. I'll look at it more later, I need the practice Configure scripts have only been added to 1.2.1 and most platforms still have an indivual makefile.\ The configure script does create a static lib here. I do notice the configure script is hand written. You could make the static lib then run dllar.cmd on it to create a DLL etc. I notice ux2bs doesn't seem to have dllar.cmd You might want to look at the DLL_FAQ in the win32 directory and maybe for now just build a static version Dave --_=_=_=IMA.BOUNDARY.HXG99L138764=_=_=_ Content-Type: application/octet-stream; name="exedefault.def" Content-Transfer-Encoding: base64 TkFNRSBXSU5ET1dDT01QQVQNClNUQUNLU0laRSAzMjc2OA0K --_=_=_=IMA.BOUNDARY.HXG99L138764=_=_=_-- **= Email 6 ==========================** Date: Sun, 9 May 2004 19:17:38 +0100 From: Stefan.Neis at t-online.de Subject: Re: Linking with external regex.lib Hi, > How do I indicate in a Makefile, that I want an app to link with an > external regex.lib which can be found via LIBRARY_PATH? If it's autoconf/configure based, that should be determined automagically. If it isn't for some reason, or if you otherwise need to hand-edit the Makefile, put "-lregex" at the _end_ of the line containing the linker command. Note however, that there are different flavours of regex libraries (unicode aware vs. ASCII only, GNU regex vs. GNU rx etc.), so you need to be sure that the external lib you put in is compatible with what the application expects. Regards, Stefan **= Email 7 ==========================** Date: Sun, 9 May 2004 18:55:39 +0100 From: John Poltorak Subject: Re: Bind On Mon, May 10, 2004 at 02:27:15AM +1000, IanM wrote: > Sidenote, I've got back on the bind case with v8.4.4 which compiles a lot > further out of the box with the latest GCC, Is that because of the compiler or the headers? It would be nice to have a bind update. I hate to see ports abandoned. > it runs but I cant make it bind to a > single IP address, wants to bind to every IP address, and recursion doesnt > turn off. The IPv6 code in it though has to be turned off, obviously. > > I'm comiling it using the AIX gcc makefile and includes, with some > replacement .h files from the OS/2 tcp/ip toolkit. > > Seems to get a lot further that using the earlier BSD POSIX stuff > which caused me no end of grief. I was wondering what would be the consequences of updating the headers in the include\arpa directory with the latest BSD versions. Is that what you are referring to? > Just need to find the time to really site down and finish it, the last > couple of years I seem to lack the staying power that programming > requires. I know what you mean. > Cheers > IanM > http://www.os2site.com/ > > Santa's elves are just a bunch of subordinate Clauses. -- John **= Email 8 ==========================** Date: Sun, 9 May 2004 19:02:25 +0100 From: John Poltorak Subject: Re: distcc On Sun, May 09, 2004 at 04:47:02PM +0100, Stefan.Neis at t-online.de wrote: > Hi. > > > > One thing IIRC you > > > said you used -Zomf. This won't work as distcc forks and OMF builds do not allow forking > > > > I used -Zomf to make it compile, which it does as a result. I'm not sure > > of the implications of fork not working. Does it mean the app won't work > > at all? > > Exactly. Probably just the behaviour you currently observe... > > > What does it do instead of fork? > > Good question. Nothing useful, in any case. I wonder, why there even > is (apparently) a stub for it, getting a linker error for trying to > compile something using fork with -Zomf would be more helpful, IMHO. Can you suggest how I can progress this? Should I just look for fork() in the source code and change it for something more appropriate under OS/2? distcc does sound like a useful program, and I would like to see if it can be made to work on OS/2. > Regards, > Stefan > > -- John **= Email 9 ==========================** Date: Sun, 9 May 2004 19:20:11 +0100 From: John Poltorak Subject: Re: zlib.def On Sun, May 09, 2004 at 09:53:45AM -0800, Dave Yeo wrote: > On Sun, 9 May 2004 12:11:03 +0100, John Poltorak wrote: > >I can't work out what exedefault.def is supposed to be or where I can find > >it. > > Woops, here it is. Thanks, for that. > > > >As for the Makefile, how would it need to be changed to turn it into a > >Makefile.in? If possible, I would like to build ZLIB using the supplied > >configure script, and that might work with some changes to the Makefile.in > >which comes included. > > It could be done, though you'd have to call something like make z.dll and it would break compatibility with Linux. I'll look at it more later, I need the practice I'm sure most of us could improve out knowledge of how Makefiles get built ;-)... I've noticed that with ZLIB v1.2.1 the Makefile is just copy of Makefile.in, so maybe the ZLIB developers themselves don't understand their way around the wonders of automake & co... I notice Makefile.in includes:- EXE= I can't figure out the point of that at all. Shouldn't it be:- EXE= at EXEEXT at or somesuch? > Configure scripts have only been added to 1.2.1 and most platforms still have an indivual makefile.\ It would probably make life simpler if they used configure.in, but maybe they don't know how... > The configure script does create a static lib here. I do notice the configure script is hand written. You could make the static lib then run dllar.cmd on it to create a DLL etc. I notice ux2bs doesn't seem to have dllar.cmd It would have if I understood the point of it. Where do I find the most recent version? > You might want to look at the DLL_FAQ in the win32 directory and maybe for now just build a static version > Dave -- John **= Email 10 ==========================** Date: Sun, 09 May 2004 12:21:37 -0800 From: "Dave Yeo" Subject: Re: zlib.def On Sun, 9 May 2004 19:20:11 +0100, John Poltorak wrote: > >I've noticed that with ZLIB v1.2.1 the Makefile is just copy of >Makefile.in, so maybe the ZLIB developers themselves don't understand >their way around the wonders of automake & co... > >I notice Makefile.in includes:- > >EXE= > >I can't figure out the point of that at all. Shouldn't it be:- > > >EXE= at EXEEXT at > >or somesuch? If you edit configure about line #80 there is a line that is CYGWIN* | Cygwin* | cygwin* ) change it to CYGWIN* | Cygwin* | cygwin* | OS/2*) and exe gets added to the binaries. > > > >> Configure scripts have only been added to 1.2.1 and most platforms still have an indivual makefile.\ > >It would probably make life simpler if they used configure.in, but maybe >they don't know how... > >> The configure script does create a static lib here. I do notice the configure script is hand written. You could make the static lib then run dllar.cmd on it to create a DLL etc. I notice ux2bs doesn't seem to have dllar.cmd > >It would have if I understood the point of it. Dllar.cmd converts a static lib into a DLL, import lib and static lib > >Where do I find the most recent version? IIRC it is distributed with newer GCCs. Just tested the one that ships with Innoteks GCC and it seems to work excepting a lxlite error at the end. It does find more imports then are officially exported but this can be changed on the command line. Also can build zlib with mmap support. Configure looks for mman.h in include/sys while the OS/2 port is in include. Also needs -lmmap added somewhere Dave **= Email 11 ==========================** Date: Sun, 9 May 2004 21:24:56 +0100 From: John Poltorak Subject: Re: zlib.def On Sun, May 09, 2004 at 12:21:37PM -0800, Dave Yeo wrote: > >I can't figure out the point of that at all. Shouldn't it be:- > > > > > >EXE= at EXEEXT at > > > >or somesuch? > > If you edit configure about line #80 there is a line that is > CYGWIN* | Cygwin* | cygwin* ) > change it to > CYGWIN* | Cygwin* | cygwin* | OS/2*) > and exe gets added to the binaries. Well spotted! I've just asked the ZLIB maintainers to add this to ZLIB. It would be nice to get it built on OS/2 straight out of the box. > >> The configure script does create a static lib here. I do notice the configure script is hand written. You could make the static lib then run dllar.cmd on it to create a DLL etc. I notice ux2bs doesn't seem to have dllar.cmd > > > >It would have if I understood the point of it. > > Dllar.cmd converts a static lib into a DLL, import lib and static lib Would it makes sense to incorporate it into the GNU Autotools, possibly libtool so it's use could become transparent? > >Where do I find the most recent version? > > IIRC it is distributed with newer GCCs. Just tested the one that ships > with Innoteks GCC and it seems to work excepting a lxlite error at the > end. It does find more imports then are officially exported but this > can be changed on the command line. > > Also can build zlib with mmap support. You're just blinding me with technobabble now ;-)... > Configure looks for mman.h in > include/sys while the OS/2 port is in include. Also needs -lmmap added > somewhere It's in include/sys in Posix/2. > Dave -- John **= Email 12 ==========================** Date: Sun, 9 May 2004 22:30:06 +0100 From: Stefan.Neis at t-online.de Subject: Re: distcc Hi, > Can you suggest how I can progress this? > > Should I just look for fork() in the source code and change it for > something more appropriate under OS/2? Well, there are three ways to handle it: 1. Look at the source code, be lucky and find out that fork() is used in combination with exec*() to accomplish what spawn*() is doing on DOS, Windows and OS/2 systems (Unix doesn't have something like spawn). Patch the code to use fork/exec combination on Unix only and spawn on the DOS-like systems, submit a patch. 2. If you're less lucky and fork is used in a less trivial way, you can more or less rewrite the whole thing, e.g. based on threads - _not_ easy. 3. Compile and link without -Zomf and use "normal" ar instead of emxomfar. For large executables, this is inefficient, though. Regards, Stefan **= Email 13 ==========================** Date: Sun, 9 May 2004 22:42:33 +0100 From: Stefan.Neis at t-online.de Subject: Re: zlib.def Hi, > > Dllar.cmd converts a static lib into a DLL, import lib and static lib > > Would it makes sense to incorporate it into the GNU Autotools, possibly > libtool so it's use could become transparent? The concept of libtool is that you compile everything twice, once to put it into a static lib, once for a DLL/shared object. Compiling things just once and then running a special program to generate the DLL from the static lib is too much for it - I don't have much hope that this could either be easily be integrated or that libtool maintainers would be willing to accept such a change. So, IMHO, the easiest thing is to "configure" with "--disable-shared" and to run dllar.cmd manually on relevant libs, possibly rebuilding the executables afterwards. > > >Where do I find the most recent version? > > > > IIRC it is distributed with newer GCCs. Just tested the one that ships > > with Innoteks GCC and it seems to work excepting a lxlite error at the > > end. Wrong lxlite version? lxlite is notoriously changing its command line flags in incompatible ways. After updating to lxlite 1.3.3, Innotek's dllar.cmd worked for me without errors. Regards, Stefan **= Email 14 ==========================** Date: Sun, 9 May 2004 22:02:34 +0100 From: John Poltorak Subject: Re: zlib.def On Sun, May 09, 2004 at 10:42:33PM +0100, Stefan.Neis at t-online.de wrote: > "--disable-shared" and to run dllar.cmd manually on relevant libs, possibly > rebuilding the executables afterwards. Running something *manually* sounds error-prone to me. It means knowing that it has to be done, how to do it and when. So much scope for getting it wrong. There must be some way of getting it automatically included in a Makefile... Maybe we could have some sort of OS/2 Automake macro for invoking dllr.cmd at the appropriate time... > Regards, > Stefan -- John **= Email 15 ==========================** Date: Sun, 9 May 2004 23:10:09 +0100 From: John Poltorak Subject: Format of DEF files Is there any description on the format of DEF files? Do keywords have to come in a particular order? I would like to put DESCRIPTION on the first line. Is that not allowed? -- John **= Email 16 ==========================** Date: Mon, 10 May 2004 01:10:38 +0200 (CEST) From: "Sebastian Wittmeier" Subject: Re: Format of DEF files On Sun, 9 May 2004 23:10:09 +0100, John Poltorak wrote: > >Is there any description on the format of DEF files? > >Do keywords have to come in a particular order? I would like to put >DESCRIPTION on the first line. Is that not allowed? From TOOLSREF.INF (Developer's Toolkit)  If you use a NAME, LIBRARY, VIRTUAL DEVICE, or PHYSICAL DEVICE statement, it must precede all other statements in the module definition file.  You can include source level comments in the module definition file by beginning a line with a semicolon (;). Such lines are ignored.  All module definition keywords (such as NAME, LIBRARY, and OLD) must be entered in uppercase letters. (There is more to it. I only pasted the introduction). Sebastian **= Email 17 ==========================** Date: Sun, 09 May 2004 20:04:12 -0800 From: "Dave Yeo" Subject: Re: zlib.def On Sun, 9 May 2004 22:42:33 +0100, Stefan.Neis at t-online.de wrote: >> > IIRC it is distributed with newer GCCs. Just tested the one that ships >> > with Innoteks GCC and it seems to work excepting a lxlite error at the >> > end. > >Wrong lxlite version? lxlite is notoriously changing its command line >flags in incompatible ways. After updating to lxlite 1.3.3, Innotek's >dllar.cmd worked for me without errors. Actually the problem was using a TVFS drive. Lxlite tried to create a /backup directory and failed Dave **= Email 18 ==========================** Date: Sun, 09 May 2004 20:20:43 -0800 From: "Dave Yeo" Subject: Re: distcc On Sun, 9 May 2004 22:30:06 +0100, Stefan.Neis at t-online.de wrote: >1. Look at the source code, be lucky and find out that fork() is used > in combination with exec*() to accomplish what spawn*() is doing on > DOS, Windows and OS/2 systems (Unix doesn't have something like spawn). > Patch the code to use fork/exec combination on Unix only and spawn > on the DOS-like systems, submit a patch. Well it is basically forking and execvp to start another program (the compiler) in the same process. They are planning on implementing spawn for cygwin. The problem I see is comunication between the child process and parent. Unluckily I don't know enough to change things here Is execvp a *nix function? Dave **= Email 19 ==========================** Date: Mon, 10 May 2004 10:32:35 +0100 From: John Poltorak Subject: Re: distcc On Sun, May 09, 2004 at 08:20:43PM -0800, Dave Yeo wrote: > On Sun, 9 May 2004 22:30:06 +0100, Stefan.Neis at t-online.de wrote: > > >1. Look at the source code, be lucky and find out that fork() is used > > in combination with exec*() to accomplish what spawn*() is doing on > > DOS, Windows and OS/2 systems (Unix doesn't have something like spawn). > > Patch the code to use fork/exec combination on Unix only and spawn > > on the DOS-like systems, submit a patch. > > Well it is basically forking and execvp to start another program (the compiler) in the same process. They are planning on implementing spawn for cygwin. The problem I see is comunication between the child process and parent. Unluckily I don't know enough to change things here Is execvp a *nix function? This sounds as though it must be a problem which has been frequently encountered. Maybe one of these two docs can provide some guidance:- http://posix2.sourceforge.net/guide.html http://homepages.tu-darmstadt.de/~st002279/os2/html/porting.html > Dave -- John **= Email 20 ==========================** Date: Mon, 10 May 2004 10:43:58 +0100 From: John Poltorak Subject: ZLIB & minigzip Looking at the build of ZLIB, there are a couple of binary executables created including minigzip. If anyone has a Unix system could you tell me if these programs actually get installed anywhere? It appears to me that they are only created for test purposes but do not get installed in $bindir so there may not be any need to install them in the OS/2 Makefile for ZLIB... -- John **= Email 21 ==========================** Date: Mon, 10 May 2004 11:17:15 +0100 From: John Poltorak Subject: Re: zlib.def On Sun, May 09, 2004 at 09:53:45AM -0800, Dave Yeo wrote: > On Sun, 9 May 2004 12:11:03 +0100, John Poltorak wrote: > > >gcc: exedefault.def: No such file or directory > >make: *** [example.exe] Error 1 > > > > > >I can't work out what exedefault.def is supposed to be or where I can find > >it. > > Woops, here it is. NAME WINDOWCOMPAT STACKSIZE 32768 Can these options be incorporated into LDFLAGS somehow? -- John **= Email 22 ==========================** Date: Mon, 10 May 2004 12:44:44 +0200 (CEST) From: "Sebastian Wittmeier" Subject: Re: OOO_1_1_1 On Sun, 9 May 2004 14:48:49 +0100, John Poltorak wrote: >On Sun, May 09, 2004 at 04:20:41AM +0200, Sebastian Wittmeier wrote: >> That's where Everblue comes into play ... > >So what is the current status of Everblue? We don't seem to hear much >about it these days. All the former developers have left it a long time ago (Antony Curtis, Brian Smith, and others). Now I'm the only one left. I took the whole project over and got even Gimp to run. But it was very unstable and there were some design flaws in it (as I can say in retrospect). So in the last weeks I began to redesign everything. That phase is nearly finished now, so that I can begin to make all the library functions work again (with the new backend). Small programs will work in few days, the big ones in months. It would be nice, if you include many small X11 programs in UX2BS. I will try to test and debug Everblue with all of them so that the two projects can mature together. If you want to stay uptodate, join the everblue-dev yahoo mailing list - it has very low traffic. Sebastian **= Email 23 ==========================** Date: Mon, 10 May 2004 11:59:59 +0100 From: John Poltorak Subject: Re: OOO_1_1_1 On Mon, May 10, 2004 at 12:44:44PM +0200, Sebastian Wittmeier wrote: > On Sun, 9 May 2004 14:48:49 +0100, John Poltorak wrote: > > >On Sun, May 09, 2004 at 04:20:41AM +0200, Sebastian Wittmeier wrote: > >> That's where Everblue comes into play ... > > > >So what is the current status of Everblue? We don't seem to hear much > >about it these days. > > All the former developers have left it a long time ago (Antony Curtis, > Brian Smith, and others). > Now I'm the only one left. I took the whole project over and got even > Gimp to run. > But it was very unstable and there were some design flaws in it (as I > can say in retrospect). > > So in the last weeks I began to redesign everything. That phase is > nearly finished now, so that I can begin to make all the library > functions work again (with the new backend). Small programs will work > in few days, the big ones in months. > > It would be nice, if you include many small X11 programs in UX2BS. I was hoping to do that, that's why I have now included Xprog44.zip in the baseline toolset, but I haven't found any suitable apps. I'd welcome any suggestions... > I will try to test and debug Everblue with all of them so that the two > projects can mature together. > > If you want to stay uptodate, join the everblue-dev yahoo mailing list > - it has very low traffic. I'm not too keen on yahoo lists, but I'll try and check it out. > Sebastian -- John **= Email 24 ==========================** Date: Mon, 10 May 2004 12:16:52 +0100 From: John Poltorak Subject: Perl - $OSNAME Does Perl provide the builtin variable $OSNAME? I've been looking at a Perl configure script which includes the code:- print("Unrecognized OSNAME='$OSNAME'. No default possible\n"); $OSNAME is shown as os2 but I have no idea where it comes from and wondered if it was a builtin function.... -- John **= Email 25 ==========================** Date: Mon, 10 May 2004 13:31:38 +0200 (CEST) From: "Sebastian Wittmeier" Subject: Re: Perl - $OSNAME On Mon, 10 May 2004 12:16:52 +0100, John Poltorak wrote: >$OSNAME is shown as os2 but I have no idea where it comes from and >wondered if it was a builtin function.... from configure (l. 3042 at 5.8.3) if $test -f $uname; then set X $myuname shift .... case "$1" in .... os2) osname=os2 osvers="$4" ;; What configure script are you talking about? Sebastian **= Email 26 ==========================** Date: Mon, 10 May 2004 13:07:58 +0100 From: John Poltorak Subject: Re: Perl - $OSNAME On Mon, May 10, 2004 at 01:31:38PM +0200, Sebastian Wittmeier wrote: > On Mon, 10 May 2004 12:16:52 +0100, John Poltorak wrote: > > >$OSNAME is shown as os2 but I have no idea where it comes from and > >wondered if it was a builtin function.... > > from configure (l. 3042 at 5.8.3) > if $test -f $uname; then > set X $myuname > shift > ... > case "$1" in > ... > os2) osname=os2 > osvers="$4" > ;; > > What configure script are you talking about? netpbm:- http://easynews.dl.sourceforge.net/sourceforge/netpbm/netpbm-10.18.12.tgz buildtools\configure.pl > Sebastian -- John **= Email 27 ==========================** Date: Mon, 10 May 2004 14:40:11 +0200 (CEST) From: "Sebastian Wittmeier" Subject: Re: Perl - $OSNAME On Mon, 10 May 2004 13:07:58 +0100, John Poltorak wrote: >On Mon, May 10, 2004 at 01:31:38PM +0200, Sebastian Wittmeier wrote: >> On Mon, 10 May 2004 12:16:52 +0100, John Poltorak wrote: >> >> >$OSNAME is shown as os2 but I have no idea where it comes from and >> >wondered if it was a builtin function.... http://www.sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/pod/perlvar ..html#item_%24OSNAME says it is a predefined config variable and redirects you to http://www.sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/lib/Config. html the value "os2" is determined at the place I mentioned in the last post, and is saved in \usr\lib\perl5\5.8.3\os2\Config.pm Sebastian **= Email 28 ==========================** Date: Mon, 10 May 2004 13:54:36 +0100 From: John Poltorak Subject: NETPBM Looking through an old OS/2 port of NETPBM here:- http://hobbes.nmsu.edu/pub/os2/dev/mm/netpbma.zip it says, in README.OS2 that:- Executables are dynamically linked, no code changes were required. But looking at the port the contents appear completely different to the extent that I wonder i this is the same app. I wonder if the original OS/2 Makefile would provide any assistance in getting NETPBM ported. The usual Autoconf/configure root looks like a non-starter. -- John **= Email 29 ==========================** Date: Mon, 10 May 2004 15:13:38 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: zlib.def John Poltorak schrieb: > NAME WINDOWCOMPAT > STACKSIZE 32768 > > > Can these options be incorporated into LDFLAGS somehow? IIRC, WINDOWCOMPAT is default anyway, stacksize for OMF builds can be set by something like -Zlinker /STACK:32768, IIRC. For setting the stacksize of a.out builds, I always rely on the default, which seems to reasonably well choosen. Otherwise, the only thing you can do instead of using a .def file is running emxbind with suitable parameters after linking. Regards, Stefan