From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 18 Jun 2003 14:07:08 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 131 ************************************************** Tuesday 17 June 2003 Number 131 ************************************************** Subjects for today 1 Re: libc : Henry Sobotka 2 Re: [EMX] Re: libc : Stefan Neis 3 Re: [EMX] Re: libc : Stefan Neis 4 Re: libc : Stefan Neis 5 Re: libc : Stefan Neis 6 Re: libc : Adrian Gschwend" 7 Re: [EMX] Re: libc : Holger Veit 8 Re: [EMX] Re: libc : Holger Veit 9 Re: [EMX] Re: libc : Stefan Neis 10 Re: libc : Andreas Buening 11 Re: [EMX] Re: libc : Andreas Buening **= Email 1 ==========================** Date: Wed, 18 Jun 2003 00:47:33 -0400 From: Henry Sobotka Subject: Re: libc I agree with Stefan's proposal that we start with EMX, i.e. create a repository with 0.9d, fix 04: emx/include and emx/src is probably all we need; though what about emx/bsd? With a vanilla EMX repository, people who are already running patched versions can check out the tree, diff it against their own EMX, patch their working directory and submit the diffs for check-in. It might also be worth creating a development branch from the outset, and applying the patches to it. Then, whenever people feel there's enough substance to warrant a release, merge with the trunk and deliver a stable runtime. For the build system, I suggest sticking with it as is for now, and converting to GNU make in two stages: 1) translate the dmakese into gmakese; 2) hack the GNU makefiles into the build system we want. This way any lack of progress with the build system won't impede development of the library's contents. h~ **= Email 2 ==========================** Date: Wed, 18 Jun 2003 11:12:44 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Tue, 17 Jun 2003, Holger Veit wrote: > > Huh? Which ones? I always had the impression that EMX's licence is rather > > permissive... > > The old GPL debate. GPL is not free, it is rather restricted. Too restricted > to be acceptable for people who need tailored version of the software. Is it GPL for the library? And even if the C runtime DLL is GPL'ed, what's the effect on executables that happen to be usable together with that specific DLL? > EMX tried some > balance there with the effect that some Unix things work, and some OS/2 > things work, and special cases don't, in both areas. I'm under the impression that our aim would be to move that "balance" closer to Unix, while InnoTek seems to try to move it closer to Win and "native" OS/2. > > Whether the CVS is rooted at netlabs or sourceforge (we could start by > > abusing the Posix/2 CVS) is rather irrelevant to me, however it would be > > great to automatically send all CVS commits (as a diff) to some dedicated > > mailing list (I know that wxWindows did such a thing also while the CVS > > was hosted by sourceforge, so it's possible to set it up like this even > > there - but I don't know, how to do it), so whoever is interested has a > > chance to check things easily. > > Meanwhile, with rather limited time, I second that fully. By now, I wonder if "cvs diff" is that much more uncomfortable for a "small" project like this... > complicated was the IMHO too complex interwoven system of dependencies > in order to build the various variants of linraries from a single source > tree. It needs some time to untangle this, but this is something that has > to be done before any further work. BTW, we should also determine what libraries we do want to build. I'd suggest to drop at least single-threaded libraries and maybe even static ones... > Look at the way it is done in "real" Unix. Well, I don't really know that much about "real" Unix libc internals... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Wed, 18 Jun 2003 11:22:51 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Tue, 17 Jun 2003, Andreas Buening wrote: > I'd like to keep the standalone libs like intl and pthreads out of emx. > Lots of Unix system also have standalone versions of them so it's > more important to get them working than to integrate them into emx. > However, the details have to be discussed. Well, the problem is that pthreads is not really a standalone library, currently it redefines a couple of file related functions to its own extended version, which causes some trouble if you are using stuff like some_class::open. If one tries to clean this up, one ends up with more dependencies on linking order (i.e. you have to link pthreads library prior to other libraries defining file I/O functions). > How do other systems solve this problem? Do they use an internal > fseek_64() replacement which is used by default instead of fseek()? There typically is fseek() (32-bit version) and fseek_64(). If -D_FILE_OFFSET_BITS=64 is given on compilation, fseek() is typically "somehow" mapped to fseek_64(). And you better avoid mixing the two in the same binary. (i.e. either compile _everything_ (including every helper library) with that library, or nothing). Similar to the problems with single- and multi-threaded libc in EMX. That's why I suggested to have only the large file enabled version in a new library. It would eliminate all the problems of unintentionally mixing the two variants. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Wed, 18 Jun 2003 11:42:17 +0200 (CEST) From: Stefan Neis Subject: Re: libc On Tue, 17 Jun 2003, Knut St. Osmundsen wrote: > Now, I just wanna say that I do not see any reasons why there should be several > efforts provding gcc and libc for OS/2. Right. OTOH, we want to simplify life for people trying to port unix software to OS/2. Ideally, "sh ./configure && make" should be enough, so the libc must be quite unix-compatible. > PS. Holger, by the by, named exports sucks performance wise on OS/2 - period - . I keep hearing: a) "named exports suck" b) That's only true for antique versions of OS/2. Any modern version of OS/2 with any remotely reasonable amount of RAM can use named exports without noticeable cost in performance. Could you experts please agree some time on whether or not b) is true? Regards, Stefan **= Email 5 ==========================** Date: Wed, 18 Jun 2003 11:51:59 +0200 (CEST) From: Stefan Neis Subject: Re: libc On Wed, 18 Jun 2003, Henry Sobotka wrote: > I agree with Stefan's proposal that we start with EMX I wonder if waiting for InnoTek's libc and starting with that wouldn't be an easier approach. Some of the things I hear sound rather good, though others don't really, but to form an opinion we'd probably really have to have a look at it... > It might also be worth creating a development branch from the outset, > and applying the patches to it. Then, whenever people feel there's > enough substance to warrant a release, merge with the trunk and deliver > a stable runtime. Sounds like a good idea, though it seems a bit unusual (to me at least) to do it that way round. > For the build system, I suggest sticking with it as is for now, and > converting to GNU make in two stages: 1) translate the dmakese into > gmakese; 2) hack the GNU makefiles into the build system we want. This > way any lack of progress with the build system won't impede development > of the library's contents. Sounds very good. Also that enables a nice separation of tasks, i.e. if somebody is working on makefiles, he won't necessarily be bothered with bugs in the evolving C code... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Wed, 18 Jun 2003 12:04:06 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: libc On Wed, 18 Jun 2003 11:51:59 +0200 (CEST), Stefan Neis wrote: >I wonder if waiting for InnoTek's libc and starting with that wouldn't >be an easier approach. Some of the things I hear sound rather good, though >others don't really, but to form an opinion we'd probably really have to >have a look at it... Achim recommends to wait, he told there might be a release before the end of month. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 7 ==========================** Date: Wed, 18 Jun 2003 12:06:16 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Wed, Jun 18, 2003 at 11:12:44AM +0200, Stefan Neis wrote: > On Tue, 17 Jun 2003, Holger Veit wrote: > > > > Huh? Which ones? I always had the impression that EMX's licence is rather > > > permissive... > > > > The old GPL debate. GPL is not free, it is rather restricted. Too restricted > > to be acceptable for people who need tailored version of the software. > > Is it GPL for the library? And even if the C runtime DLL is GPL'ed, what's > the effect on executables that happen to be usable together with that > specific DLL? Don't try to debate on this; I do know differences between GPL and LGPL and their implications. The point is: if some commercial customer says NO to GPL, for whatever reason (even because of ignorance), then this customer is away. Period. And this is IMHO exactly the motivation why Innotek tries to avoid the buzzword GPL like the devil avoids holy water. Understandable. > > EMX tried some > > balance there with the effect that some Unix things work, and some OS/2 > > things work, and special cases don't, in both areas. > > I'm under the impression that our aim would be to move that "balance" > closer to Unix, while InnoTek seems to try to move it closer to Win and > "native" OS/2. My impression as well. > > complicated was the IMHO too complex interwoven system of dependencies > > in order to build the various variants of linraries from a single source > > tree. It needs some time to untangle this, but this is something that has > > to be done before any further work. > > BTW, we should also determine what libraries we do want to build. I'd > suggest to drop at least single-threaded libraries and maybe even static > ones... Multithreaded, in flavours "optimized" and "debuggable". Everything else is stuff to consider for later (read: if some complains about missing stuff, then why shouldn't he/she add this to the project - YGWYPF). > > Look at the way it is done in "real" Unix. > > Well, I don't really know that much about "real" Unix libc internals... "Real" Unix as in *BSD and Linux ;-) There is a lot of stuff to see. Holger **= Email 8 ==========================** Date: Wed, 18 Jun 2003 12:21:46 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Wed, Jun 18, 2003 at 11:22:51AM +0200, Stefan Neis wrote: > On Tue, 17 Jun 2003, Andreas Buening wrote: [...] > > How do other systems solve this problem? Do they use an internal > > fseek_64() replacement which is used by default instead of fseek()? > > There typically is fseek() (32-bit version) and fseek_64(). > If -D_FILE_OFFSET_BITS=64 is given on compilation, fseek() is typically > "somehow" mapped to fseek_64(). And you better avoid mixing the two in > the same binary. (i.e. either compile _everything_ (including every helper > library) with that library, or nothing). Similar to the problems > with single- and multi-threaded libc in EMX. That's why I suggested to > have only the large file enabled version in a new library. It would > eliminate all the problems of unintentionally mixing the two variants. The fseek vs fseek64 is yet another example of broken Unix API design. Effectively, this revolves around the problem whether off_t has been designed as 32 bit (as usual) or as 64 bit right from the beginning. Since most Unixes started broken by concept with the old 'long' offset type, this had to be "fixed" later when designers "suddenly" detected that their Unix filesystems were designed for Terabytes of storage and disks meanwhile approached the size of 2GB (which is ridiculously small nowadays). Result was this awkward *_64() patches which required specific programming and compilation. We only have to preserve compatibility in that we need some fseek() and fseek_64() at all, not with binary compatibility with existing code (this can still access the old EMX DLLs and will be happy). If we need to touch the header files already then my proposal is to typedef longlong off_t; and prototype int fseek(FILE*,off_t,int); and implement int fseek_64(FILE* f,off_t off,int whence) { return fseek(f,off,whence); } The fseek code will itself fall down to a 64 bit compliant lseek(), and this will, depending on the presence of Dos*L routines or not (loadable DLL module) decide whether to accept the call or not if an offset >2GB is specified. Holger **= Email 9 ==========================** Date: Wed, 18 Jun 2003 15:53:37 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Wed, 18 Jun 2003, Holger Veit wrote: > If we need to touch the header files already then my proposal is to > typedef longlong off_t; > and prototype > int fseek(FILE*,off_t,int); > and implement > int fseek_64(FILE* f,off_t off,int whence) { return fseek(f,off,whence); } > > The fseek code will itself fall down to a 64 bit compliant lseek(), and > this will, depending on the presence of Dos*L routines or not (loadable > DLL module) decide whether to accept the call or not if an offset >2GB is > specified. That's what I had in mind as well. And maybe it's also what InnoTek did do (though I suppose they would have completely ommited the fseek_64). BTW, is there a mail loop? I keep getting my own mail about GPL again and again ... Regards, Stefan **= Email 10 ==========================** Date: Wed, 18 Jun 2003 19:48:41 +0200 From: Andreas Buening Subject: Re: libc Knut St. Osmundsen wrote: [snip] > Build system isn't an issue anylonger, and even if it were, there are millions > of them (allready responsible for 10+ (closed and open) myself). (If anything, a > working GNU make is of much better use than yet another build system - the > latest port is leaking a file/pipe handle everytime it's spawning a child, and > -j is broken.) Which make version? [snip] Bye, Andreas **= Email 11 ==========================** Date: Wed, 18 Jun 2003 19:48:49 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Holger Veit wrote: [snip] > We only have to preserve compatibility in that we need some fseek() and > fseek_64() at all, not with binary compatibility with existing code > (this can still access the old EMX DLLs and will be happy). I can understand why you'd like to break binary compatibility. However, I have a bad feeling about doing this. Some libraries do this sometimes and this leads to a set of incompatible binary files which can become quite nasty. I'd like to keep also binary compatibility. [snip] Bye, Andreas