From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 24 Jun 2003 14:07:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 137 ************************************************** Monday 23 June 2003 Number 137 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Stefan Neis 2 Re: [EMX] Re: libc : Stefan Neis 3 Re: [EMX] Re: libc : Stefan Neis **= Email 1 ==========================** Date: Tue, 24 Jun 2003 14:28:06 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003, Ilya Zakharevich wrote: > For example, if you have 0 "third-party C++", then your argument does > not make sense. Given that a "C++ library" is an oxymoron anyway, I > do not expect you to have much more than 0. ;-) If you put a 1 in front of that 0, you're approximately right. For C libraries, it's about the same (mostly XFree related), but recompiling shouldn't be a problem if it's necessary. > > Any prominent example of such a library would help me see the > > problem. I can't think of any. > > No concrete example comes to my mind - though tar.exe is "very close" > to be an example. You have the source, but you can't recompile (due > to an orthogonal reason to what we discuss, though). IIRC, there are newer versions which are compilable, though missing some esoteric feature... Regards, Stefan **= Email 2 ==========================** Date: Tue, 24 Jun 2003 14:56:40 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Mon, 23 Jun 2003, Andreas Buening wrote: > b) Functions with new behaviour (like set/getuid): > - 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). > > 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) However, as Ilya pointed out, this doesn't solve the problems for old libraries (binaries), which don't reference the ordinal, just the function name... Regards, Stefan **= Email 3 ==========================** Date: Tue, 24 Jun 2003 18:13:51 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Tue, 24 Jun 2003, Ilya Zakharevich wrote: > I do not see how this could be a problem. First of all, EMX CRT DLL > has no exports by name, right? [Can't check it now.] I think so yes. But (static) libraries typically don't reference DLL entry points, do they? I think they just reference function names which get resolved to DLL entry points or whatever at link time? > The problem with libraries which I meant is that a function could take > off_t as an argument (or a return value). If the meaning of off_t > changes in the calling program, but not in the library (or visa > versa), this leads to problems which are extremely hard to debug. Oh, yes. That's something I learned under Solaris and Linux and that's why I keep saying that following their scheme is not a very good idea. OTOH, if you want to continue existing libraries without recompilation, that's impossible to avoid. Personally, I tend to recommend to recompile everything once and be done with the problem, instead of fighting with those flags for years (and get "extremely hard to debug" problems every now and then because some library you are using was compiled the wrong way...), but I do see your point. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'.