Date: Mon, 19 Jan 2004 00:07:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 259 ************************************************** Sunday 18 January 2004 Number 259 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : Andreas Buening 2 Re: Any new UX2BS testers? : Stefan.Neis at t-online.de 3 Re: Any new UX2BS testers? : Andreas Buening **= Email 1 ==========================** Date: Sat, 17 Jan 2004 15:36:18 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Stefan.Neis at t-online.de wrote: > > Andreas Buening schrieb: > > In fact, Linux is not Unix. While Linux installations > > seem to use > > libfoo-x.y.z.so other Unix systems don't do so. > > That's x.y.z before .so is just part of the library name, feel > free to ignore on other systems. The interesting part is > the x.y.z in something.so.x.y.z, which is similar to Solaris > numbering... What I wanted to tell, is that none of the systems above uses libtool numbering like libfoo.so.1.2.3. Especially Solaris and Irix use only _one_ number. I assume that this number refers to some kind of binary compatibility release number which is actively maintained. Many libs are still called "lib*.so.1" although I doubt that all of them still have the internal version number 1.0.0. And, every system has got only _one_ version of each library. Which again means that there is some kind of intelligence which a) decides whether the new version is incompatible to the old one and increments the .so.n number by one b) removes all old programs using the old version by new programs using the new version This prohibits a version chaos which would occur otherwise if every tiny bugfix release would get its own .so.x.y.z file and would never be removed. > > I've checked /lib > > and /usr/lib of AIX, Solaris and Irix. While AIX has only > > .a files > > without any version numbers, > > Well, why have numbers for static libs? I'm not sure whether these are really static libs. AIX has some strange features. [snip] > > What is a developer > > of a program supposed to do? Should he link everything > > statically? > > should he ship his executable with all (un)necessary > > dlls? Should he > > write a README file which lists all dlls + version which > > are required? > > At least the README is going to be necessary, no matter > what you do, isn't it? A README, yes, but not a novel. If there are several requirements which are listed, then there is a high probability that one or more of them are not available because - the server is down - the directory structure has changed - the file has been replaced by a new version And, of course, all these required packages also have README files and further requirements. Beyond a certain point I ask whether this program is worth wasting several hours for the installations, and the answer is "no". > > And your libtool magic doesn't prevent you from > > encountering > > people who create their own intl0A.dll because "libtool > > doesn't work", > > "export by ordinal is much better", "I use tool xyz to > > create my dlls". > > Well, if you intentionally create an incompatible DLL, you > are likely going to not put any version number into it (at > least that's how it worked until now). But if you do, you > hopefully are not going to reuse the same thats being used > by an incompatible DLL... There are many versions of intl.dll using different names. Once a version numbering scheme has become popular, you'll see that different people create libraries using this scheme but their private techniques. [snip] > > This just means: If we use static linking then we don't > > need to discuss shared libraries. > > Sorry, my point was, that it is silly to have tons of DLLs > of just a few KBs. It's not worth the overhead of loading > DLL/"resolving symbols" at runtime. It depends on where you set the limit. For a 2 kb DLL I agree, but for a 50 kb dll it makes sense. > There are legitimate uses of DLL, but if someone is > porting one single program, he should think about statically > linking e.g. libz in preference of distributing yet another > z.DLL that's incompatible with existing versions. He should think first about linking a portable z.dll (if there were one). > > > And you break all programs that relied on the > > > bug or which happened to add a workaround for > > > it around the call of the "buggy" function. > > > > You have the same problem if you update your OS/2 system. > > Maybe a program relies on a bug in doscall1.dll or any other > > fixed dll. > > That's why later fixpacks occasionally revert changes of earlier > ones, and someone at IBM has to come up with a different way > to fix the 30 programs involved without breaking the 31st. I don't know details about IBM's internal way to fix bugs. From my user's perspective I can trust that OS/2 is backward compatible, i.e. I can be sure that a program or a device driver, that worked 5 years ago, will still work in 2009 (with the exception of bugs which occur e.g., on fast cpus). I don't have to care whether the program/driver is 16 bit or uses the xyz API or whatever since old APIs aren't removed. I don't have to care about release numbers of dlls. If I have a driver for my printer, graphics or sound card, then I have a driver for this piece of hardware. The driver usually won't stop working because of an system upgrade like it may happen on Win* systems (at least I heard lots of rumors about it ;-) ). [long snip] Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Sat, 17 Jan 2004 18:55:42 +0100 From: Stefan.Neis at t-online.de Subject: Re: Any new UX2BS testers? Hi, > I assume that this number refers to some kind of > binary compatibility release number which is actively maintained. Looking at wxWindows (which doesn't use libtool), this is exactly what's happening, but we are following the exact rules given by libtool - or at least that's what the people actually doing the numbering keep telling. So, I _guess_ libtool has some possibility to actively feed such a number to it (because I don't see how it could possibly determine it automatically). So, assuming the fact that we do have such a compatiblity number which is actively maintained, why would we ignore it? (No, it's definitely _not_ just the library version number, e.g. GTK+-1.2.10 comes with libgtk-1.2.so.0.9.1 and libglib-1.2.so.0.0.10 which IIRC is supposed to indicate that e.g. libglib-1.2 is still compatible with it's very first version, while libgtk-1.2 is at its ninth extended version (i.e. you should be able to replace older versions by the newer one without trouble but if you try it the other way round, you might get missing symbols). According to the suggested numebring scheme, these could become something like gtk1209.dll and glib1200.dll on OS/2 (12 being part of the name, 09 and 00 being the actual version numbers). OK, I admit that I'm a bit unsure if it's really worth having that second digit of the version number, after all, programs requiring e.g. gtk1203.dll should still run perfectly well with gtk1209.dll. OTOH, having a program which says "requires gtk120.dll" and doesn't work with the gtk120.dll that's installed on my system (because it really requires what is named gtk1209.dll in the suggested numbering scheme and what I have is only gtk1203.dll) can also be very frustrating. (Currently used name is gtk12.dll, so newer programs not working with the installed version of the DLL is exactly what happened to me.) Now, if we ommit that second digit and additionally ommit the first digit as long as it's zero, we still have a mostly reasonable numbering system (with the drawback I just described) and won't normally see any version numbers. BTW, on Linux, I'm actually distributing my application together with the GTK+ libraries that where used to compile it, because the different versions are _not_ as compatible as the numbering claims them to be - versions that are too new break the program just as well as versions that are too old. > And, every system has got only _one_ version of each library. Which > again means that there is some kind of intelligence which > a) decides whether the new version is incompatible to the old one > and increments the .so.n number by one > b) removes all old programs using the old version by new programs > using the new version Guess who is recompiling all old programs included e.g. in Solaris/IRIX/AIX on such occasions? Right, it's SUN/SGI/IBM. Now, who is going to (be able to) recompile all old programs if I replace e.g. Z.DLL by a new version? Also, those companies all take backwards compatibility very seriously. If you take a program compiled on e.g. Solaris 2.5, you can still run it on Solaris 10, without having to install tons of libraries. Try the same with e.g. SuSE-7.2 vs. SuSE-9.0... Those libraries, that we are typically porting just are changing much faster in incompatible ways than any system library of a commercial (non-Windows) system. > This prohibits a version chaos which would occur otherwise if > every tiny bugfix release would get its own .so.x.y.z file and > would never be removed. Tiny bugfixes are supposed to only affect the last number in libtool, which was suggested to be ignored anyway! > A README, yes, but not a novel. If there are several requirements which > are listed, then there is a high probability that one or more of them > are not available because > - the server is down > - the directory structure has changed > - the file has been replaced by a new version > And, of course, all these required packages also have README files > and further requirements. Beyond a certain point I ask whether this > program is worth wasting several hours for the installations, and the > answer is "no". Well, that reminds my of my last try to use "xfig" on OS/2 (and part of the problem was to find the "right" DLLs for some auxiliary stuff - with 3 and more incompatible versions available that all had the same name) Unfortunately, I _really_ needed it. In the end, I managed to get _one_ version of xfig to work, IIRC it was the third one I tried ... I don't see, how it's going to get worse if version numbers are included in DLL names. > There are many versions of intl.dll using different names. Once a version > numbering scheme has become popular, you'll see that different people > create libraries using this scheme but their private techniques. Which means they will be unable to run a bunch of other people's software. Seems unlikely to me... > It depends on where you set the limit. For a 2 kb DLL I agree, > but for a 50 kb dll it makes sense. Even if it's needed by exactly one programs (e.g. old versions of diff and sed and their incompatible versions of gnuregex.dll)? > He should think first about linking a portable z.dll (if there > were one). How do you find it, even if there is one? > I don't know details about IBM's internal way to fix bugs. From my > user's perspective I can trust that OS/2 is backward compatible, i.e. > I can be sure that a program or a device driver, that worked 5 years > ago, will still work in 2009 Exactly. But the same is _not_ true for Linux and it's libraries, at least not without major effort in installing outdated shared objects. And just linking the missing libraries to the new version which is installed, does _not_ work. Now, why do you insist on naming those DLLs the same, even if it will break programs that are a bit older? (> e.g., on fast cpus). I don't have to care whether the program/driver > is 16 bit or uses the xyz API or whatever since old APIs aren't removed. >From OS/2's _system_ DLLs, right. Libraries ported from Linux are different! > I don't have to care about release numbers of dlls. For _system_ DLLs. Again, DLLs generated from libraries ported from Linux are _very_ different. I do not like this either, but that's the way it is, what's the point in ignoring reality? Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Sat, 17 Jan 2004 20:11:34 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Stefan.Neis at t-online.de wrote: > > Hi, > > > I assume that this number refers to some kind of > > binary compatibility release number which is actively maintained. > > Looking at wxWindows (which doesn't use libtool), this is exactly what's > happening, but we are following the exact rules given by libtool - or at > least that's what the people actually doing the numbering keep telling. > > So, I _guess_ libtool has some possibility to actively feed such a > number to it (because I don't see how it could possibly determine > it automatically). I don't doubt that there is some magic flag for libtool which does magic stuff, but, how? ;-) > So, assuming the fact that we do have such a > compatiblity number which is actively maintained, why would we ignore it? Now we're talking about different things. If there is anything like a "binary release number" which means that the versions _are_ in fact not binary compatible and that they can't be made compatible by just playing around with the module definition file and that they can't be made compatible by a tiny patch to the source code that will be accepted by the maintainer, then and only then we have no choice other than to use a new dll name. But I refuse to deal with zillions of new dll names just because the new version _could_ possibly be incompatible to the old one (if nobody has ever checked this). In the case of the famous intl.dll all existing versions (with the only exception of the binary release of 0.10.40 because it's missing a symbol) can be made binary compatible when dealing with the module definition file. These are the 0.10.x and 0.11.x versions (I haven't looked closely at 0.12.x but I think it's similar). [snip] > Now, if we ommit that second digit and additionally ommit the first > digit as long as it's zero, we still have a mostly reasonable numbering > system (with the drawback I just described) and won't normally see any > version numbers. This is basically, what we IMHO should do. [snip] > Guess who is recompiling all old programs included e.g. in > Solaris/IRIX/AIX on such occasions? Right, it's SUN/SGI/IBM. Exactly. And the programs for UnixOS/2 should be compiled by the UnixOS/2 people (at least, in theory). [snip] > Also, those companies all take backwards compatibility very seriously. > If you take a program compiled on e.g. Solaris 2.5, you can still > run it on Solaris 10, without having to install tons of libraries. > Try the same with e.g. SuSE-7.2 vs. SuSE-9.0... This is no reason for us to use the worst example from the real world. ;-) IMHO, if we use the Linux philosophy for compatibility then we'll end up in chaos since we have not the capabilities to release a new distro every few months and to recompile all old programs. > Those libraries, that we are typically porting just are changing > much faster in incompatible ways than any system library of a > commercial (non-Windows) system. Then distribute only stable releases as dlls and everything als static library or as beta release. [xfig] > I don't see, how it's going to get worse if version numbers are included > in DLL names. Except that you may have to install the same dlls (but with different version) over and over and over again. > > There are many versions of intl.dll using different names. Once a version > > numbering scheme has become popular, you'll see that different people > > create libraries using this scheme but their private techniques. > > Which means they will be unable to run a bunch of other people's software. > Seems unlikely to me... You just have to write your own dll with export by ordinals (because it's faster), and as soon as somebody wants to use your program with the official dll (export by name): *BOOM* > > It depends on where you set the limit. For a 2 kb DLL I agree, > > but for a 50 kb dll it makes sense. > > Even if it's needed by exactly one programs (e.g. old versions of diff > and sed and their incompatible versions of gnuregex.dll)? Of course, a dll for just one program doesn't make any sense. That's not the meaning of "shared". ;-) However, having an libfooxx.dll for every single program isn't really different from that. [snip] > I do not like this either, but that's the way it is, what's the point in > ignoring reality? Who wants to be bothered by reality? ;-))) Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs