From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 23 Jun 2003 14:07:16 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 136 ************************************************** Sunday 22 June 2003 Number 136 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : nickk" 2 Re: [EMX] Re: libc : Andrew Belov" 3 Re: [EMX] Re: libc : Stefan Neis 4 Re: [EMX] Re: libc : Stefan Neis 5 Re: [EMX] Re: libc : Stefan Neis 6 Re: [EMX] Re: libc : Stefan Neis 7 Re: [EMX] Re: libc : Sebastian Wittmeier (ShadoW)" 8 Re: [EMX] Re: libc : Andreas Buening 9 Re: [EMX] Re: libc : Andreas Buening **= Email 1 ==========================** Date: Mon, 23 Jun 2003 10:35:48 +0400 (MSD) From: "nickk" Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003 18:32:50 +0200 (CEST), Sebastian Wittmeier (ShadoW) wrote: >There is not much choice anymore with compilers on OS/2. >So writing OS/2 programs with gcc is more important than ever. Thus there is no progress in OS/2 itself (kernels, etc), then why we need new compilers for it ? The existing ones such is VAC, Watcom are sufficient to make progs in OS/2. I dont know any example of using gcc/emx to write new big native os/2 project. **= Email 2 ==========================** Date: Mon, 23 Jun 2003 11:42:40 +0300 (MSK) From: "Andrew Belov" Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003 10:35:48 +0400 (MSD), nickk wrote: >On Sun, 22 Jun 2003 18:32:50 +0200 (CEST), Sebastian Wittmeier (ShadoW) wrote: > >>There is not much choice anymore with compilers on OS/2. >>So writing OS/2 programs with gcc is more important than ever. > >Thus there is no progress in OS/2 itself (kernels, etc), then why we need new compilers for it ? The existing ones such is VAC, Watcom are sufficient to >make progs in OS/2. I dont know any example of using gcc/emx to write new big native os/2 project. The recent versions of GCC are superior in terms of optimization. When it comes to optimization for a particular modern CPU (archivers/packers are a vivid example - the data amounts grow along with CPU power), GCC v 3.2.1 is my choice. **= Email 3 ==========================** Date: Mon, 23 Jun 2003 16:08:20 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003, Ilya Zakharevich wrote: > On Sun, Jun 22, 2003 at 06:05:18PM +0200, Stefan Neis wrote: > > > I don't know why EMX needs C++ internally. > > > > It doesn't. But if you want to be able to use C++, that needs some support > > deep in the internals of EMX. > > Could you elaborate on this? Not really, as I don't really know the details, so I'm just guessing. Anyway, exception handling with C++-code called from C-code (e.g. main()) sounds like said C-code must be aware of some of the internals of C++. > No, it is not. At least not with most of them, who do not do any seek. So why do I need the non-large-file enabled stuff at all? > The situation is not that simple. Your forgot about linking with old > libraries. For C++ that's routinely broken with every gcc update, so I don't feel a big urge to go through hoops to avoid doing it _once_ for C as well. Regqards, Stefan **= Email 4 ==========================** Date: Mon, 23 Jun 2003 16:24:46 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003, Ilya Zakharevich wrote: > > handle big ones. You surely want to add such garbage to autoconf/automake > > rulesets, don't you? > > ??? It is already there, since all the major players do it this way. Sure, CXXLAGS="-DSOME_LARGE_FILE_MACRO" CFLAGS="-DSOME_LARGE_FILE_MACRO" ./configure Great! And if some sub-library has (not) been using the flag while you did (not), the stuff that you will get after hours of configure/make process is just garbage. It works as long as _everybody_ is either ignoring the flag or _everybody_ is using it. Why would I want to duplicate all those problems on OS/2? > Since the program in question has no way to get a uid which is !=0, > there is no need to do anything else to port it. There are some multi-user additions being developped, so setuid might well be able to get a uid != 0 in the not so distant future. > Yes, bug-for-bug compatibility is a bad target; and 0.1% of programs > will break no matter how careful you are. But numbers matter; on many > systems LIBPATHSTRICT will help, and given a very few failing > programs, a wrapper is a viable solution. What good is LIBPATHSTRICT if DLL's with different names are used anyway? > > of acceptance by "the community", or precisely, by a number of speakers > > with their own agendas. libemu, or Posix/2, is an example of code that > > was not accepted by the community, in that it was regularly used in ports > > and continously improved to weed out the bugs. Why? My opinion is: > > I never believed that anything would come out of this (but I hoped > nevertheless that it would). Actually, I do not remember what it > wanted to be; A simple layer of BSD compatibility function in addition to what EMX provides. > but IIRC, it tried to solve problems which are mostly > irrelevant (i.e., take very little proportion of porting time) by > making some "magic actions" (like opening a "wrong file"), and by some > pipe dreaming ("let us design a new program loader"). None of those is related to Posix/2 (at least not at its current state). Actually, trying to use it on a larger scale for UnixOS/2, the biggest problem was software already containing own workarounds for stuff missing in EMX, so one ends up with duplicate symbols (e.g. setuid and various others). Patching e.g. perl accordingly is a minor problem, but people tend to not want patching working stuff... Regards, Stefan **= Email 5 ==========================** Date: Mon, 23 Jun 2003 18:03:45 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003, Ilya Zakharevich wrote: > > There are some multi-user additions being developped, so setuid might well > > be able to get a uid != 0 in the not so distant future. > > ??? We were discussing *existing* programs, did not we? So what? Since "porting" often consists of "./configure && make" there are programs which rely on set/getuid to work on OS/2 just the same as on Unix. Mailing lists are full of question like "what can I do to get application xyz working, it's falling on set/getuid, strncasecmp, whatever". > ??? This whole discussion is about making old programs work better > without recompile (by maintaining EMX again). Using DLLs with > different names is an orthogonal topic. No sorry. The whole discussion is about making old programs work better by recompiling with a new libc and leaving old programs as they are. At least that was my impression... :-/ > > Actually, trying to use it on a larger scale for UnixOS/2, the biggest > > problem was software already containing own workarounds for stuff missing > > in EMX, so one ends up with duplicate symbols (e.g. setuid and various > > others). Patching e.g. perl accordingly is a minor problem, but people > > tend to not want patching working stuff... > > How many packages (in percents) worked out-of-the-box? Say 20% of the previously "fixed" ones ("broken" in terms of Posix/2), which was all that was tested. In most instances, removing some #ifdef __EMX__ various rubbish #endif was sufficient to solve the problems, two packages turned up real bugs in Posix/2 (fixed by now). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Mon, 23 Jun 2003 18:10:32 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003, Ilya Zakharevich wrote: > > > > It doesn't. But if you want to be able to use C++, that needs some support > > > > deep in the internals of EMX. > > > > > > Could you elaborate on this? > > > > Not really, as I don't really know the details, so I'm just guessing. > > Well, I doubt it very much that *any* support is needed. I had the impression that both EM and Holger implied that such a thing would be necessary. Might have been a misunderstanding on my part. > > > No, it is not. At least not with most of them, who do not do any seek. > > > > So why do I need the non-large-file enabled stuff at all? > > ??? If you want to read/read more than 2G, you *must* inform the OS > about this. This is what DosOpenL() is about. What's wrong about _always_ using DosOpenL() (if available) and use 64 bit values for seek related stuff if most programs do not do any seek anyway? > > > The situation is not that simple. Your forgot about linking with old > > > libraries. > > > For C++ that's routinely broken with every gcc update, so I don't feel > > a big urge to go through hoops to avoid doing it _once_ for C as well. > > For all the third-party libraries on your system? Exactly. If I have to do it for the bunch of all the third-party C++ libraries, what's the problem with doing it for a few C libraries that might be on my system? > You just can't. > Some part of them won't recompile - even if you have the source - > would would not hold for some of them. Any prominent example of such a library would help me see the problem. I can't think of any. Regards, Stefan **= Email 7 ==========================** Date: Mon, 23 Jun 2003 18:22:02 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003 07:46:21 -0700, Ilya Zakharevich wrote: >> There are some multi-user additions being developped, so setuid might well >> be able to get a uid != 0 in the not so distant future. >??? We were discussing *existing* programs, did not we? If we want to make "old programs work better without recompile" and OS/2 gets multi-user capable, setuid won't be a dummy function any longer, and will return the real uid. Some existing ports can't handle that added functionality. Either we leave the old setuid dummy for old programs (no improvement for existing programs), or we change the setuid (some existing programs cease to work correctly). Sebastian **= Email 8 ==========================** Date: Mon, 23 Jun 2003 22:13:22 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Sebastian Wittmeier (ShadoW) wrote: > > On Mon, 23 Jun 2003 07:46:21 -0700, Ilya Zakharevich wrote: > > >> There are some multi-user additions being developped, so setuid might well > >> be able to get a uid != 0 in the not so distant future. > > >??? We were discussing *existing* programs, did not we? > > If we want to make "old programs work better without recompile" and > OS/2 gets multi-user capable, setuid won't be a dummy function any > longer, and will return the real uid. Some existing ports can't handle > that added functionality. Either we leave the old setuid dummy for old > programs (no improvement for existing programs), or we change the > setuid (some existing programs cease to work correctly). Apart from broken ports that define their own set/getuid(), is there any reason why the program behaviour should rely on the current emx behaviour? At the moment I can't think of any example but I've never dealt with this API extensively. I mean no code will contain something like if (getuid() != -1) system("rm -fR /"); ;-) And for the case OS/2 might ever get multiuser capabilities, If a program can't deal with user IDs or permissions then it can't deal with user IDs or permissions (like a typical DOS program). In this case it's irrelevant whether you use this program with the old emx library (which doesn't support users) or the new libc (which does support users but the programs doesn't know). If you enable your multiuser capabilities and the program fails then it fails unless you want to run it as root. As far as I can see we have three kinds of function problems: a) Functions that have to be added (like the all times favorite strcasecmp): No problem, doesn't hurt old programs. b) Functions with new behaviour (like set/getuid): - Current sources may contain dummy defines; nasty but must be removed anyway, - Old programs (binaries): Not effected if we keep the old ordinal number and the broken old function together (the new implementation of the function gets a new ordinal number). - Alternatively we don't keep the old implementation and the program has to deal with the new (correct) behaviour. We can decide this differently for every function depending on how likely is a software failure for this case. c) Functions that change its declaration (like fseek if we change to 64 bit by default; how many of them are there?): - Old programs (binaries): If we want to keep binary compatibility the old function must keep its ordinal (but may get a new name -> fseek32) - We can make the new behaviour (fseek64) the default and still provide a macro to switch to the old behaviour. Bye, Andreas **= Email 9 ==========================** Date: Mon, 23 Jun 2003 22:13:39 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Stefan Neis wrote: > > On Sun, 22 Jun 2003, Ilya Zakharevich wrote: > > > > handle big ones. You surely want to add such garbage to autoconf/automake > > > rulesets, don't you? > > > > ??? It is already there, since all the major players do it this way. > > Sure, > CXXLAGS="-DSOME_LARGE_FILE_MACRO" CFLAGS="-DSOME_LARGE_FILE_MACRO" ./configure > Great! And if some sub-library has (not) been using the flag while you did > (not), the stuff that you will get after hours of configure/make process > is just garbage. It works as long as _everybody_ is either ignoring the > flag or _everybody_ is using it. To avoid this I'd say we should do it the other way around and make the "new" (reasonable) behaviour the default. People (== programmers) should be aware that the next emx (or whatever) release will be a major one. If still anybody needs 32bit support he is free to do so and to define 20 macros for this purpose. We could provide a big _EMX_OLD_BEHAVIOUR macro that includes all other "old style" macros but that's it. And, of course, there has to be the definition that all UnixOS/2 (tm) libraries have to use e.g. large file support. [snip] Bye, Andreas