From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 11 Mar 2002 04:19:25 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 160 ************************************************** Sunday 10 March 2002 Number 160 ************************************************** Subjects for today 1 Re: Make problem : Jun Sawataishi 2 Re: Make problem with Gettext 0.11 : Jun Sawataishi 3 Re: Make problem : Jun Sawataishi 4 Re: Make problem : Holger Veit 5 Re: Make problem : Holger Veit 6 Re: (un)protoize : John Poltorak 7 Re: Migrating from gcc 2.8.1 to 3.0.3 : John Poltorak 8 Fetchmail v5.9.10 : John Poltorak 9 Re: Make problem : John Poltorak 10 Re: c++filt : Andrew Zabolotny" 11 Re: (un)protoize : Andrew Zabolotny" 12 Re: Identifying sh.exe : Andrew Zabolotny" 13 Re: Migrating from gcc 2.8.1 to 3.0.3 : Andrew Zabolotny" 14 -funroll-loops and _optlink : Andrew Zabolotny" 15 Re: INFO2INF ? : Andrew Zabolotny" 16 Re: -funroll-loops and _optlink : Henry Sobotka 17 Re: Gettext 0.11 : John Poltorak 18 Re: $UNIXROOT - time for a decision : Holger Veit 19 $UNIXROOT - time for a decision : Andrew Zabolotny" 20 Re: cc1plus in gcc 3.0.3 ? : Andrew Zabolotny" 21 Re: gcc 3.0.3 - cross-compiler? : Andrew Zabolotny" 22 Gettext 0.11 : Andrew Zabolotny" 23 Re: $UNIXROOT - time for a decision : Henry Sobotka 24 Re: Make problem with Gettext 0.11 : John Poltorak 25 Re: Make problem with Gettext 0.11 : Andreas Buening 26 Problem with shell variables : John Poltorak 27 Re: $UNIXROOT - time for a decision : Andreas Buening 28 Re: Gettext 0.11 : Andreas Buening 29 Re: Make problem with Gettext 0.11 : Andreas Buening 30 zlib security advisery : Dave and Natalie" **= Email 1 ==========================** Date: Mon, 11 Mar 2002 02:34:27 +0900 From: Jun Sawataishi Subject: Re: Make problem On UNIXROOT env. var, Holger wrote: John P.>And what if the appropriate file system structure is not present there? >You end up in complicated, and *thus necessarily* failing heuristics >to locate things like /etc/passwd, /etc/hosts, /etc/services >(are they in boot:\tcpip\etc or in boot:\mptn\etc or in %ETC% or >even elsewhere). And these prominent files are just the simple cases? >Where to obtain certain settings? Holger>XFree86/OS2 (and even to some degree EMX itself) is the well-known example >that ordinary users cannot read docs that say "do first this, then that, >and finally this". So any system that offers flexibility and provides >complicated heuristics to identify messed up file and data structures >is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. After consideration, I completely agreed with Holger. From now on, I rewrite sources: When UNIXROOT env. var. is not set or empty, programs will say "set UNIXROOT env. var." and terminate. # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 2 ==========================** Date: Mon, 11 Mar 2002 02:37:56 +0900 From: Jun Sawataishi Subject: Re: Make problem with Gettext 0.11 John P>According to README.OS2 in gettext-0.11:- >2. Go to os2 and just run `make'. If you have all the required tools, >it should painlessly compile. >Here is what I get when using Make 3.79.1:- >sed: -e expression #1, char 8: Unterminated address regex > ...................... How about correct lines this way From sed '...........' to sed "........" Maybe a buggy feature of a shell # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 3 ==========================** Date: Mon, 11 Mar 2002 02:50:51 +0900 From: Jun Sawataishi Subject: Re: Make problem John P>I always like it best when things work automagically without anything >needing to be set by the user. Keeping it simple means having sensible >defaults. I would also like it if most utilities such SED, GREP, AWK etc >would work indepedently of UnixOS/2 which they wouldn't if %UNIXROOT% was >a prerequisite. Now, I disagree with you. When program searches for "$UNIXROOT/usr/libexec/foo" : If UNIXROOT is absent and c:/usr/libexec/foo is absent, the program will fail and an end-user will face a problem. He/She will not be able to know how to fix the problem. When UNIXROOT is not set, program should show a message and terminate; this is a simple and the best way, I think. How about issueing a certificate of UNIXOS2 to programs behave like this way? # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 4 ==========================** Date: Mon, 11 Mar 2002 07:56:11 +0100 From: Holger Veit Subject: Re: Make problem On Sun, Mar 10, 2002 at 07:33:38PM +0000, John Poltorak wrote: > > > If ETC has two locations, which is what will happen if UNIXROOT != > > > bootdrive then people will be forced to maintain two copies of various > > > config files, > > > > Which ones? > > RESOLV RESOLV2? > PASSWD Not used by OS/2 software, but by broken ports - several variants. > GROUP Not used by OS/2 software, but by broken ports - several variants. > TERMCAP Controlled by TERMCAP variable. > SERVICES Incomplete and outdated in OS/2 TCP/IP > NAMED.CONF Almost noone runs a name server. > NETRC > WGETRC Not used by OS/2 software, but but ad-hoc defined by some incompatible port > .NEWSRC This belongs into your HOME directory regularly. > In principle it just a mess having ETC being split over two locations and > its just asking for something to go wrong sooner or later. You have provided examples that won't be any problem any longer when UNIXOS/2 is in place, unless you want to keep incompatible ports side-by-side with it. But then you are fully on your own, and have no reason to complain about UNIXOS/2. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 5 ==========================** Date: Mon, 11 Mar 2002 07:58:04 +0100 From: Holger Veit Subject: Re: Make problem On Sun, Mar 10, 2002 at 07:41:45PM +0000, John Poltorak wrote: [...] > > Holger>XFree86/OS2 (and even to some degree EMX itself) is the well-known example > > >that ordinary users cannot read docs that say "do first this, then that, > > >and finally this". So any system that offers flexibility and provides > > >complicated heuristics to identify messed up file and data structures > > >is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. > > > > After consideration, I completely agreed with Holger. > > From now on, I rewrite sources: > > When UNIXROOT env. var. is not set or empty, programs will > > say "set UNIXROOT env. var." and terminate. > > I don't think you should do that. If anything is going to check for the > presence of %UNIXROOT% it should be the LIBEMU runtime environment. That > would be the correct place to have any environment checking. It doesn't > make sense for a single program to have such code. Unixrootify is an emulation technique to work as long as LIBEMU doesn't do the same jobe for any port. So, it should also behave in the same way as the future code. 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: Mon, 11 Mar 2002 09:30:29 +0000 From: John Poltorak Subject: Re: (un)protoize On Mon, Mar 11, 2002 at 11:12:39AM +0300, Andrew Zabolotny wrote: > On Thu, 21 Feb 2002 20:41:52 +0000, John Poltorak wrote: > > >gcc v3.0.3 has a couple of programs, protoize and unprotoize, which are > >missing from the OS/2 port. I have no idea what they are but would prefer > >to include them in a GCC package if possible. Does anyone know where I > >coud get them? > these are some obscure tools for adapting K&R vanilla C code to ANSI C. They > do something with function prototypes, such as converting to and from this > kind of definitions: > > void something (int x, float y) > { > ... > } > > void something(x, y) > int x; > float y; > { > ... > } > > I don't know where they appear from, the Makefile doesn't build them by > default. If you want them so much, I will take a look where they come from. I just wanted them for the sake of completion so that a gcc package would be functionally equivalent to a gcc package on Linux, although it seems that no one would use them anyway. > Greetings, > _\ndy > > -- John **= Email 7 ==========================** Date: Mon, 11 Mar 2002 09:39:22 +0000 From: John Poltorak Subject: Re: Migrating from gcc 2.8.1 to 3.0.3 On Mon, Mar 11, 2002 at 11:22:32AM +0300, Andrew Zabolotny wrote: > On Sat, 23 Feb 2002 10:20:19 +0000, John Poltorak wrote: > > >Is it possible to move to gcc v3.0.3 without using any binaries from > >v2.8.1? Or is there a requirement to install over the top of 2.8.1? > >I'm ignoring include and lib and any documentation, just the files which > >normally go in bin. I'm thinking about programs like NM, LISTOMF etc... > No. My releases of gcc were always meant to be installed on top of EMX. There > are many tools which are shared between emx and my port of gcc. And I don't > think I will do it ever, since if I will ever put some more work in gcc/2, I'm > going to evolve the ELF branch, which will be self-contained. > > Maybe unixos2 should contain a complete self-contained distributive of gcc, but > you will have to build it yourself. That's my intention, but I'm not sure how much of emx\bin is required. I think there are quite a few DOS programs that could be left out... > Greetings, > _\ndy > > -- John **= Email 8 ==========================** Date: Mon, 11 Mar 2002 09:49:21 +0000 From: John Poltorak Subject: Fetchmail v5.9.10 The 5.9.10 release of fetchmail is now available at the usual locations, including . The source archive is available at: Does anyone know if this version will build on OS/2? I know that OS/2 was one of the platforms it would build on several years ago, but then the OS/2 maintainer disappeared, although there have been a couple of OS/2 ports appearing again recently... It would be nice if any OS/2 patches were bundled into the main code. -- John **= Email 9 ==========================** Date: Mon, 11 Mar 2002 10:06:16 +0000 From: John Poltorak Subject: Re: Make problem On Sun, Mar 10, 2002 at 11:25:27PM +0100, Stefan Neis wrote: > On Sun, 10 Mar 2002, Andreas Buening wrote: > > One thing is obvious: in principle we need a maintainer > > for every package that should be incorporated into unixos2 > > even if it's only for compiling the latest versions because > > every time there can ba an incompatible change of any type. > > One thing is obvious: There's no manpower for that kind of > porting. That's why Holger is aiming for something as BSD-like > as possible so every new version compiling on BSD compiles on > OS/2 automatically. What I would like to set up is some monitoring process which discovers new releases of specific apps, then automatically retreives the source and builds the app, runs any included tests and then notifies any interested parties about the results. For this to work, we need a standard build system in place and I don't hink that it too far away. > (And no, I don't really like that approach either, but I don't > believe we can do much better...). > > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 10 ==========================** Date: Mon, 11 Mar 2002 11:10:12 +0300 From: "Andrew Zabolotny" Subject: Re: c++filt On Thu, 21 Feb 2002 10:41:14 +0000, John Poltorak wrote: >Which package should c++filt appear in? >It's part of GNU gcc 3.0.3 but not included in the OS/2 port, however it >is included in the OS/2 port of binutils, but not the original. >I'm tempted to move it from BINUTILS to GCC as far as UnixOS/2 packages >are concerned. Is this going to cause any problems? c++filt is part of both gcc and binutils. But if you ask me, it looks better as part of gcc and not a part of binutils, since 1) gcc is released more often and c++filt is always up-to-date and 2) imho the mangler/demangler is part of compiler and not quite a part of binary utilites. OS/2 distribution of gcc always contains the latest version of c++filt (in the gcc-os2-*-gpp.zip archive). Greetings, _\ndy **= Email 11 ==========================** Date: Mon, 11 Mar 2002 11:12:39 +0300 From: "Andrew Zabolotny" Subject: Re: (un)protoize On Thu, 21 Feb 2002 20:41:52 +0000, John Poltorak wrote: >gcc v3.0.3 has a couple of programs, protoize and unprotoize, which are >missing from the OS/2 port. I have no idea what they are but would prefer >to include them in a GCC package if possible. Does anyone know where I >coud get them? these are some obscure tools for adapting K&R vanilla C code to ANSI C. They do something with function prototypes, such as converting to and from this kind of definitions: void something (int x, float y) { ... } void something(x, y) int x; float y; { ... } I don't know where they appear from, the Makefile doesn't build them by default. If you want them so much, I will take a look where they come from. Greetings, _\ndy **= Email 12 ==========================** Date: Mon, 11 Mar 2002 11:15:48 +0300 From: "Andrew Zabolotny" Subject: Re: Identifying sh.exe On Fri, 22 Feb 2002 14:45:03 +0000, John Poltorak wrote: >Is there any way to identify which version of shell is being used from >within a shell script? What I do know that bash sets the $BASH and $BASH_VERSION variables. Greetings, _\ndy **= Email 13 ==========================** Date: Mon, 11 Mar 2002 11:22:32 +0300 From: "Andrew Zabolotny" Subject: Re: Migrating from gcc 2.8.1 to 3.0.3 On Sat, 23 Feb 2002 10:20:19 +0000, John Poltorak wrote: >Is it possible to move to gcc v3.0.3 without using any binaries from >v2.8.1? Or is there a requirement to install over the top of 2.8.1? >I'm ignoring include and lib and any documentation, just the files which >normally go in bin. I'm thinking about programs like NM, LISTOMF etc... No. My releases of gcc were always meant to be installed on top of EMX. There are many tools which are shared between emx and my port of gcc. And I don't think I will do it ever, since if I will ever put some more work in gcc/2, I'm going to evolve the ELF branch, which will be self-contained. Maybe unixos2 should contain a complete self-contained distributive of gcc, but you will have to build it yourself. P.S. Seen the latest cygwin. I'm quite impressed with the ease of installation and upgrading, and caught the fancy of the "virtual Unix file system" over the Windows' drive letters. I think we can borrow a lot of ideas from cygwin. Greetings, _\ndy **= Email 14 ==========================** Date: Mon, 11 Mar 2002 11:38:32 +0300 From: "Andrew Zabolotny" Subject: -funroll-loops and _optlink On Sat, 23 Feb 2002 22:54:06 -0500, Henry Sobotka wrote: >> >> For those using GCC 3.03, note that the -funroll_loops option is broken >> >> (just experienced it with lame). >> >Do you mean -funroll-loops? Is the underscore instead of hyphen just a >> >typo in your message? >> Sorry, yes it is. >YAQFA (yet another question for Andy). It is not a question, it is a statement. -funroll-loops is broken in gcc 3.0.3. Period :-) Please understand that I don't like digging too much in gcc code. It is so complex, that I would have to spend some months just to understand how it works, and for what -- just to fix a bug in gcc? (and there are smarter people than me to work on it anyways). The best solution if you find a bug in gcc itself (such as wrong code being generated) is to post it through http on the gcc-bug form (it is somewhere on www.gcc.org or www.gcc.gnu.org or such). I have reported a couple of compiler errors last months and they replied quickly and proposed some fixes/workarounds whenever possible. ----------- Now about _optlink (going to rename it to _Optlink in 3.0.3 release). >> This sounds good. EM had reported long ago that the old 2.8.1 already had >> some sort of Optlink calling convention, but mentioned it would work >> for scalar types only. So, does the new optlink also work for the >> not so "simple cases" like float/double arguments (mixed with integer >> args), structure passing and returns, and pointers to obscure data types >> (like function pointers)? >Alas, no for mixed args. It just moves everything to the stack in the >prolog to a foo(int, float, double, int, double, float, long, int) call, >instead of pushing the last arg and loading the general and FP registers >as expected with the rest. (Why? - another implicit question for Andy.) >For structs I have look up how _Optlink handles them. Pointers may be >okay because IIRC they're all just treated as integral types that can go >into %eax, %edx or %ecx; nonetheless a must-test. It would be great if >we could get this working right. Please understand that I did not implemented _optlink myself. I just have adapted EM's code from gcc 2.8.1 to gcc 3.0.3. It is absolutely same functionality as in gcc 2.8.1 - _limited_ compatibility with _Optlink. With the ongoing move to ELF I don't see much sense in putting much work into it (am I wrong?). In fact, even EM's patch for "optlink" is not too complex. GNU C has its own way of using "register parameters" convention, it is called regparm (__attribute((regparm)) or such). _optlink is almost just-an-alias for it. This is the cause of incompatibilities between IBM's _Optlink and gcc's _optlink - it just happened that scalar types in regparm function are passed the same way as in _Optlink. More complex types are passed differently; of course _Optlink could be improved to include all (or most) kinds of arguments but it requires a lot of work and I'm not sure -- even until now -- that it will repay the efforts put into it. Greetings, _\ndy **= Email 15 ==========================** Date: Mon, 11 Mar 2002 11:47:31 +0300 From: "Andrew Zabolotny" Subject: Re: INFO2INF ? On Fri, 8 Mar 2002 00:58:39 +0900, Jun Sawataishi wrote: >>Has anyone come across and INFO to INF converter? >We cannnot convert INFO (converted from texinfo source using makeinfo or >emacs) to INF. To get INF file from GNU texinfo source, use texinfo to OS/2 >IPFC source code. > texinfo source ==> IPFC source ==> INF file I almost wrote a "meant-to-be-universal" TEXInfo converter (which supports the "4th version" of texinfo -- alas, the '97 texi2ipf converter doesn't support it). In the first release I'm going to support IPF and HTML outputs; just wonder where I can get some free time to work on it. It is, say, 70% complete right now. Greetings, _\ndy **= Email 16 ==========================** Date: Mon, 11 Mar 2002 12:45:49 -0500 From: Henry Sobotka Subject: Re: -funroll-loops and _optlink Andrew Zabolotny wrote: > > Please understand that I did not implemented _optlink myself. I just have > adapted EM's code from gcc 2.8.1 to gcc 3.0.3. It is absolutely same > functionality as in gcc 2.8.1 - _limited_ compatibility with _Optlink. With > the ongoing move to ELF I don't see much sense in putting much work into it > (am I wrong?). Could you please add a note to that effect to the docs for the sake of anyone who downloads 3.0.3 and hasn't seen this thread? > This is the cause of incompatibilities between IBM's _Optlink and gcc's > _optlink - it just happened that scalar types in regparm function are passed > the same way as in _Optlink. More complex types are passed differently; of > course _Optlink could be improved to include all (or most) kinds of arguments > but it requires a lot of work and I'm not sure -- even until now -- that it > will repay the efforts put into it. I agree there's more to be gained from the ELF effort than _Optlink. I see two main advantages to full _Optlink support: compatibility with VAC++ DLLs and faster code. We've managed to get by without the former until now, so it's hardly critical, not to mention the fact that icc is an abandoned compiler. As for speed gains, they only materialize where the callee immediately uses the values loaded into the registers by the caller. Also, FWIW as a very crude benchmark, users have consistently reported the pgcc builds of Mozilla to be faster than VAC++ builds, and even the latest minimally optimized (-O) gcc 3.0.3 release at least matches the speed of its more highly optimized VAC++ counterpart. This suggests that existing gcc optimization may already be better than anything _Optlink can provide. h~ **= Email 17 ==========================** Date: Mon, 11 Mar 2002 12:56:48 +0000 From: John Poltorak Subject: Re: Gettext 0.11 On Mon, Mar 11, 2002 at 03:47:12PM +0300, Andrew Zabolotny wrote: > Hello! > > I see some people is trying to compile Gettext 0.11 on OS/2. Only to try and build a new INTL.DLL... > Please don't! Alas the release was done *before* I finished to commit all > working patches to the gettext maintainer, thus the OS/2 port is in a > half-working state in gettext 0.11 :-( That's pretty sad, but it's not my fault. > It's just a sign of how the rest of the world takes us, OS2-ers into account :-) > > For now, use gettext 0.10.40. I will try to find some spare time and publish the > fixed 0.11 binaries with patches. There is a problem with INTL.DLL... The new port of Make 3.79.1 won't work with it because of a missing function. This function - nl_msg_cat_cntr does exist in a different port though... > > Greetings, > _\ndy > > -- John **= Email 18 ==========================** Date: Mon, 11 Mar 2002 14:30:43 +0100 From: Holger Veit Subject: Re: $UNIXROOT - time for a decision On Mon, Mar 11, 2002 at 03:27:29PM +0300, Andrew Zabolotny wrote: > On Thu, 7 Mar 2002 23:18:16 +0900, Jun Sawataishi wrote: > > >>So how do you get a program to use %UNIXROOT%. Is it as simple as > >>--prefix=$UNIXROOT/usr or do you have to hack the code? If so could > >>I see an example Also what happens if %UNIXROOT% isn't defined? > >>Dave > > Introduction of UNIXROOT env. var. has beed discussed a lot in this mailing > >list. I think: When porting Open Source Softwares, we __must__ make a strong > >effort to introcude UNIXROOT. > We must carefuly think what to do about it. I don't see a clear simple > solution, so I would like to start (maybe "yet another one") discussion about > it. > > 1. On one hand, if we add $UNIXROOT support to (future) libc, it will mean > that every application will work compiled "out-of-the-box" (at least without > issues concerning the filesystem incompatibilities). > > 2. On other hand, it will mean that the user will have to be aware of the > "real" filesystem (with drive letters etc) and the "virtual" filesystem > (Unix-like virtual filesystem on top of OS/2's filesystem). > > There are two approaches to this problem, and both have their pluses and > minuses: > > - One approach is to emulate a "flat" Unix-like filesystem (/bin, /etc, /tmp, > /usr/bin and so on) on top of the "drive-letter-based" one. This approach is > used in CygWin, and seems to work nicely except for the 2nd feature mentioned > above - you can't use "make" separately (say from File Commander/W) because > File Commander uses Windows filesystem and make uses CygWin's Unix filesystem > emulation layer. > > - Other approach is to patch every application separately by adding support > for miscelaneous environment variables such as GNULOCALEDIR, UNIXROOT, ETC, > TEMP&TMP and such. This approach has been more or less successfully used with > EMX/OS2 but has the disadvantage that it requires to patch every separate > application and it is hard to maintain the latest version of patched > applications. The advantage is that the application looks completely "native > OS/2". > > Here is a proposal (not a ultimate solution, just a preliminary proposal) > which tries to take the best of two approaches: > > The solution is to make a set of three filesystem filters built into the libc. > That is, libc will be able to run in three different filesystem modes. The > initial mode will be selected by some environment variable, say, UNIXOS2_FS: > > -*- "UNIXOS2_FS=native": Absolutely native filesystem mode. No filesystem > translation at all. > > -*- "UNIXOS2_FS=unix": in this mode the root is mounted to %UNIXROOT%, also > there should be a way to address to the OS/2 drives (some analogue of CygWin's > /cygdrive/c/, /cygdrive/d/ and so on -- perhaps a little shorter to type - > maybe even something like /dev/c/, /dev/d/ and so on -- or /mnt/c/, /mnt/d/). > > -*- "UNIXOS2_FS=os2": This is a compromise between the above "absolute OS/2 > conformance" and "absolute Unix compatibility" modes above. The filesystem > itself is non-translated except some widely-used prefixes such as /etc/, > /tmp/, /home/ and possible some others. The library should gather all the > available information from the environment, for example from the UNIXROOT, > ETC, TMP, TEMP environment variables. > > This environment variable will be inherited by child processes, thus the > entire process tree will work in one filesystem space. The default mode (if no > UNIXOS2_FS variable set) should be, perhaps, "unixos2". > > Say, a typical "unixos2.cmd" file would look somehow like this: > > set UNIXOS2_FS=unix > %UNIXROOT%\bin\bash > > But if you run bash directly (without UNIXOS2_FS being set, or with UNIXOS2 > _FS=os2) it will see the OS/2 filesystem "almost-natively", except that it > will find his /etc/profile, /home/user/.bashrc files normally. > > Also it should be made possible to compile applications in some "hardcoded > mode", e.g. if you write a 100% native OS/2 application you will want the > UNIXOS2_FS variable to be ignored and the filesystem to work always in > "native" mode. Or, say, you want a "half-native" application and want the > UNIXOS2_FS variable to be hardcoded to "os2" and so on. Also if you statically > link a native OS/2 application you don't want the "Unix filesystem emulation > layer" to be linked in at all. This could be accomplished by some additional > compiler flags, I believe - or maybe by adding some linker flags such as > -lfs_native, -lfs_unix and such, or even with a flag of the -Zunixos2 > _fs=native form. > > That's it in a few words. Maybe I've forgot something, just ask :) To summarize: I like such an idea, but I am afraid we run into the EMX problem particularly for the "native" portion: That is: the applications have to deal somehow with a drive letter in the pathname. Almost no app from Unix (unless it has been already written portably) does this; typical case of code, already mentioned several time is: if (path[0]=='/') { ... path is absolute } else { ... path is relative } You cannot deal with that in libc, because libc does not know what the application does with the path. You can have libc translate a "c:\foo" into "/c/foo" (this is your UNIXOS2_FS=unix), and we could make this even more flexible easily by making the translation "C:" -> "/c" variable - this is an emulation of the mount(2) syscall (and you need such kind of flexibility even to get chroot(2) correctly done). Also UNIXOS2_FS=os2 is doable, however, we have to take old Unix apps into account that themselves rely on TMP/TEMP/ETC variables to be set; the idea to hide them in libc to get mktemp/tmpname and other functions portable and flexible (/tmp vs /var/tmp) is not yet so old. So: UNIXOS2_FS=unix and UNIXOS2_FS=os2: no real concerns, but UNIXOS2_FS=native will require again the same efforts for porting we now have to do. If it were just a matter of static linking, we could get away with some "native" GREP or "native" MAKE (but then you also have the PATH problem - I can easily imagine a situation where the wrong MAKE will be called with the right GCC (or vice versa) - a matter of name space, not of wrapper scripts), but if you want to make the behaviour dynamically changeable, you'll need source code changes in the application (beyond those GNUCONFDIR or GNUDOCDIR variables that some apps already recognize), which should have been avoided with the whole UNIXROOT idea. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 19 ==========================** Date: Mon, 11 Mar 2002 15:27:29 +0300 From: "Andrew Zabolotny" Subject: $UNIXROOT - time for a decision On Thu, 7 Mar 2002 23:18:16 +0900, Jun Sawataishi wrote: >>So how do you get a program to use %UNIXROOT%. Is it as simple as >>--prefix=$UNIXROOT/usr or do you have to hack the code? If so could >>I see an example Also what happens if %UNIXROOT% isn't defined? >>Dave > Introduction of UNIXROOT env. var. has beed discussed a lot in this mailing >list. I think: When porting Open Source Softwares, we __must__ make a strong >effort to introcude UNIXROOT. We must carefuly think what to do about it. I don't see a clear simple solution, so I would like to start (maybe "yet another one") discussion about it. 1. On one hand, if we add $UNIXROOT support to (future) libc, it will mean that every application will work compiled "out-of-the-box" (at least without issues concerning the filesystem incompatibilities). 2. On other hand, it will mean that the user will have to be aware of the "real" filesystem (with drive letters etc) and the "virtual" filesystem (Unix-like virtual filesystem on top of OS/2's filesystem). There are two approaches to this problem, and both have their pluses and minuses: - One approach is to emulate a "flat" Unix-like filesystem (/bin, /etc, /tmp, /usr/bin and so on) on top of the "drive-letter-based" one. This approach is used in CygWin, and seems to work nicely except for the 2nd feature mentioned above - you can't use "make" separately (say from File Commander/W) because File Commander uses Windows filesystem and make uses CygWin's Unix filesystem emulation layer. - Other approach is to patch every application separately by adding support for miscelaneous environment variables such as GNULOCALEDIR, UNIXROOT, ETC, TEMP&TMP and such. This approach has been more or less successfully used with EMX/OS2 but has the disadvantage that it requires to patch every separate application and it is hard to maintain the latest version of patched applications. The advantage is that the application looks completely "native OS/2". Here is a proposal (not a ultimate solution, just a preliminary proposal) which tries to take the best of two approaches: The solution is to make a set of three filesystem filters built into the libc. That is, libc will be able to run in three different filesystem modes. The initial mode will be selected by some environment variable, say, UNIXOS2_FS: -*- "UNIXOS2_FS=native": Absolutely native filesystem mode. No filesystem translation at all. -*- "UNIXOS2_FS=unix": in this mode the root is mounted to %UNIXROOT%, also there should be a way to address to the OS/2 drives (some analogue of CygWin's /cygdrive/c/, /cygdrive/d/ and so on -- perhaps a little shorter to type - maybe even something like /dev/c/, /dev/d/ and so on -- or /mnt/c/, /mnt/d/). -*- "UNIXOS2_FS=os2": This is a compromise between the above "absolute OS/2 conformance" and "absolute Unix compatibility" modes above. The filesystem itself is non-translated except some widely-used prefixes such as /etc/, /tmp/, /home/ and possible some others. The library should gather all the available information from the environment, for example from the UNIXROOT, ETC, TMP, TEMP environment variables. This environment variable will be inherited by child processes, thus the entire process tree will work in one filesystem space. The default mode (if no UNIXOS2_FS variable set) should be, perhaps, "unixos2". Say, a typical "unixos2.cmd" file would look somehow like this: set UNIXOS2_FS=unix %UNIXROOT%\bin\bash But if you run bash directly (without UNIXOS2_FS being set, or with UNIXOS2 _FS=os2) it will see the OS/2 filesystem "almost-natively", except that it will find his /etc/profile, /home/user/.bashrc files normally. Also it should be made possible to compile applications in some "hardcoded mode", e.g. if you write a 100% native OS/2 application you will want the UNIXOS2_FS variable to be ignored and the filesystem to work always in "native" mode. Or, say, you want a "half-native" application and want the UNIXOS2_FS variable to be hardcoded to "os2" and so on. Also if you statically link a native OS/2 application you don't want the "Unix filesystem emulation layer" to be linked in at all. This could be accomplished by some additional compiler flags, I believe - or maybe by adding some linker flags such as -lfs_native, -lfs_unix and such, or even with a flag of the -Zunixos2 _fs=native form. That's it in a few words. Maybe I've forgot something, just ask :) Greetings, _\ndy **= Email 20 ==========================** Date: Mon, 11 Mar 2002 15:34:51 +0300 From: "Andrew Zabolotny" Subject: Re: cc1plus in gcc 3.0.3 ? On Tue, 26 Feb 2002 14:12:19 +0000, John Poltorak wrote: >Should there be a cc1plus.exe in gcc v3.0.3 or should the one from v2.8.1 >be used instead? Sure there should be one in emx/lib/gcc-lib/.../. Have you installed gcc-*-gpp.zip? Greetings, _\ndy **= Email 21 ==========================** Date: Mon, 11 Mar 2002 15:39:13 +0300 From: "Andrew Zabolotny" Subject: Re: gcc 3.0.3 - cross-compiler? On Thu, 28 Feb 2002 08:13:44 +0000, John Poltorak wrote: >I came across someone who was trying to run the Win32 version of gcc under >Odin whose target platform was the ARM embedded processor. This sounded >like an exercise in masochism, but apparently the Win32 version does >support ARM as a target platform. No, *that* gcc is a separate cross-compiler built by someone on the net. It is not the mingw32 nor cygwin gcc. Greetings, _\ndy **= Email 22 ==========================** Date: Mon, 11 Mar 2002 15:47:12 +0300 From: "Andrew Zabolotny" Subject: Gettext 0.11 Hello! I see some people is trying to compile Gettext 0.11 on OS/2. Please don't! Alas the release was done *before* I finished to commit all working patches to the gettext maintainer, thus the OS/2 port is in a half-working state in gettext 0.11 :-( That's pretty sad, but it's not my fault. It's just a sign of how the rest of the world takes us, OS2-ers into account :-) For now, use gettext 0.10.40. I will try to find some spare time and publish the fixed 0.11 binaries with patches. Greetings, _\ndy **= Email 23 ==========================** Date: Mon, 11 Mar 2002 20:24:00 -0500 From: Henry Sobotka Subject: Re: $UNIXROOT - time for a decision Andreas Buening wrote: > > If your program needs direct access to the Dos* API > to get access to the drive letters (whether it's a command line > tool, an office suite or a wps extension doesn't matter) > then you'd better use another compiler. Huh? Why? If anything, os2emx.h should be updated, not trashed. h~ **= Email 24 ==========================** Date: Mon, 11 Mar 2002 20:34:55 +0000 From: John Poltorak Subject: Re: Make problem with Gettext 0.11 On Mon, Mar 11, 2002 at 09:07:34PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > According to README.OS2 in gettext-0.11:- > > [make bug] > > Should be fixed now: ftp://ftp.unixos2.com/incoming/make-3_79_1-bin-beta4.zip > (the bug not that gettext 0.11 Makefile) Now I get:- [N:\eval\gettext\gettext-0.11\os2]make make: $SHELL changed (was `cmd.exe', now `C:\OS2\CMD.EXE') make: *** could not duplicate stdout . Stop. Is this to be expected? AZ said that Gettext v0.11 was not currently buildable on OS/2, but he hopes to get it fixed before too long. However, the previous version Gettext creates an INTL.DLL which is not usable with this new version of Make. It would be nice to try and get used to gcc 3.0.3 along with Make 3.79.1 but they don't seem to work together. Is it possible to build Make so that it can use this Gettext and INTL.DLL? :- ftp://ftp.netlabs.org/pub/gcc/gettext-os2-0.10.40-bin.zip Either that, or rebuild this Gettext so that it works with both gcc and Make... > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. -- John **= Email 25 ==========================** Date: Mon, 11 Mar 2002 21:07:34 +0100 From: Andreas Buening Subject: Re: Make problem with Gettext 0.11 John Poltorak wrote: > > According to README.OS2 in gettext-0.11:- [make bug] Should be fixed now: ftp://ftp.unixos2.com/incoming/make-3_79_1-bin-beta4.zip (the bug not that gettext 0.11 Makefile) bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 26 ==========================** Date: Mon, 11 Mar 2002 21:15:23 +0000 From: John Poltorak Subject: Problem with shell variables I have a problem trying to use a variable extracted from a file, and it is driving me nuts! Could do with someone pointing out where I'm going wrong... >cat parms abc --without-included-gt --without-included-regex xyz ----^ = \t ----^ = ' ' ----^ = \t ie *three* tab delimited fields, the second one having an embedded space. If I run:- cat parms >temp IFS=' ' #tab read p1 PARMS p3 < temp configure $PARMS I get:- configure: error: invalid package name: included-gt --without-included-regex $PARMS appears to have the correct value when ECHOed, and configure does work if I explicitly set PARMS="--without-included-gt --without-included-regex" and run configure $PARMS. This is from M4, BTW. I suspect the embedded space is tripping things up. Can anyone point out where I'm going wrong? -- john **= Email 27 ==========================** Date: Mon, 11 Mar 2002 22:12:05 +0100 From: Andreas Buening Subject: Re: $UNIXROOT - time for a decision Andrew Zabolotny wrote: [UNIXROOT] > We must carefuly think what to do about it. I don't see a clear simple > solution, Me, too. > so I would like to start (maybe "yet another one") discussion about > it. > > 1. On one hand, if we add $UNIXROOT support to (future) libc, it will mean > that every application will work compiled "out-of-the-box" (at least without > issues concerning the filesystem incompatibilities). Every _Unix_ application that hasn't got any drive letter support yet but the world is somewhat larger than Unix. > 2. On other hand, it will mean that the user will have to be aware of the > "real" filesystem (with drive letters etc) and the "virtual" filesystem > (Unix-like virtual filesystem on top of OS/2's filesystem). Not only the end user. A lot of scripts or programs currently use Unix tools with drive letters. These would be broken by Unix only filesystems (Assume a simple installation program that uses unzip: "unzip f:\install\xyz.zip" will have bad side effects if "f:" is a CD ROM drive and unzip supports only the Unix file system syntax). Additionally, for a normal user it would be very hard to memorize which programs use drive letters and which ones don't (gnuplot 3.7 does while 3.8 doesn't?). > There are two approaches to this problem, and both have their pluses and > minuses: > > - One approach is to emulate a "flat" Unix-like filesystem (/bin, /etc, /tmp, > /usr/bin and so on) on top of the "drive-letter-based" one. This approach is > used in CygWin, and seems to work nicely except for the 2nd feature mentioned > above - you can't use "make" separately (say from File Commander/W) because > File Commander uses Windows filesystem and make uses CygWin's Unix filesystem > emulation layer. In the worst case you need two versions of every tool, one to keep the unixos2 environment happy, and another to be used from commandline by hand or by other (non Unix) scripts. > - Other approach is to patch every application separately by adding support > for miscelaneous environment variables such as GNULOCALEDIR, UNIXROOT, ETC, > TEMP&TMP and such. Yes, but the number of additional variables should be reduced to the absolute minimum, i.e. UNIXROOT and perhaps TMPDIR (which seems to be some kind of standard from some GNU programs for DOS/Win). > This approach has been more or less successfully used with > EMX/OS2 but has the disadvantage that it requires to patch every separate > application and it is hard to maintain the latest version of patched > applications. The advantage is that the application looks completely "native > OS/2". Yep. [proposal] > Also it should be made possible to compile applications in some "hardcoded > mode", e.g. if you write a 100% native OS/2 application you will want the > UNIXOS2_FS variable to be ignored and the filesystem to work always in > "native" mode. Definitely yes. If your program needs direct access to the Dos* API to get access to the drive letters (whether it's a command line tool, an office suite or a wps extension doesn't matter) then you'd better use another compiler. Taking into account the number of free or commercial C/C++ compilers that are still under development (btw, is there any but gcc?) I would say that the future versions of gcc/2 must be able to compile every kind of application, and I mean _every_ (Ok, except 16 bit stuff, but that's another story). Personally, I really wouldn't like to need a filename conversion function to use e.g. grep from within a REXX script. [snip] bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 28 ==========================** Date: Mon, 11 Mar 2002 22:12:18 +0100 From: Andreas Buening Subject: Re: Gettext 0.11 Andrew Zabolotny wrote: > > Hello! > > I see some people is trying to compile Gettext 0.11 on OS/2. [snip] Why did you use a Makefile at all? Okay, configure is quite slow but it has some other advantages. (Yes, I've read your comments within that Makefile.) bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 29 ==========================** Date: Mon, 11 Mar 2002 22:33:57 +0100 From: Andreas Buening Subject: Re: Make problem with Gettext 0.11 John Poltorak wrote: > > On Mon, Mar 11, 2002 at 09:07:34PM +0100, Andreas Buening wrote: > > John Poltorak wrote: > > > > > > According to README.OS2 in gettext-0.11:- > > > > [make bug] > > > > Should be fixed now: ftp://ftp.unixos2.com/incoming/make-3_79_1-bin-beta4.zip > > (the bug not that gettext 0.11 Makefile) > > Now I get:- > > [N:\eval\gettext\gettext-0.11\os2]make > make: $SHELL changed (was `cmd.exe', now `C:\OS2\CMD.EXE') > make: *** could not duplicate stdout > . Stop. > > Is this to be expected? Definitely not. Could you add "-h256" (or any other large number) to your %EMXOPT% before calling make? [snip] bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 30 ==========================** Date: Mon, 11 Mar 2002 23:17:54 +0000 From: "Dave and Natalie" Subject: zlib security advisery Does this apply to OS/2? http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html Dave