Date: Wed, 14 Jan 2004 00:07:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 258 ************************************************** Tuesday 13 January 2004 Number 258 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : Andreas Buening 2 Re: Any new UX2BS testers? : Andreas Buening 3 Re: Any new UX2BS testers? : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Mon, 12 Jan 2004 21:32:36 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Stefan.Neis at t-online.de wrote: > > Andreas Buening schrieb: [binary compatibility] > Then, why does Linux go through so many hoops > to do exactly that kind of numbering on the > shared objects that you claim to be > unnecessary on OS/2? Are all those people just > being stupid? The fact, that something is done in the Linux world, doesn't automatically mean that is the right or the wrong way to do it. ;-) In fact, Linux is not Unix. While Linux installations seem to use libfoo-x.y.z.so other Unix systems don't do so. I've checked /lib and /usr/lib of AIX, Solaris and Irix. While AIX has only .a files without any version numbers, the other systems use *.so files which are symbolic links to *.so.1 files (in some cases also .2 up to .7). And these files are real. I assume, these numbers specify the release according to binary compatibility. [snip] > Actually, adding a new default argument is > rather common in C++, it doesn't even require > changing existing source, just recompiling > and relinking. ;-) C++ is a completely different issue. There is no consistent name mangling, and therefore every compiler or even every different release of every compiler uses a different symbol for the same function. So, yes, if we're talking about C++ and if a library is supposed to work on different computers, then static linking should be used, IMHO. And in C, changing the arguments of a function is a rather uncommon practise since it either needs some preprocessor macros to emulate the old behaviour or a rewrite of all program codes. > > This leads to zillions of dlls of nearly the same name > > because everybody > > uses his own preferred version for linking "his" > > programs. > > And this is _good_. Some time ago, I couldn't > use a current make and gcc-3.0.3 at the same > time since both required "intl.dll" but > neither would work with the version that the > other program did like. Having one link with > intlAx.dll and one with intlBy.dll would have > avoided that nightmare. No, it is NOT good. Taking alone the discussions about "program xyz doesn't work because gcc?????.dll is not found. Where can I find this dll?" tells me that you would have to install lots of old and crazy dlls for lots of programs. 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? 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". [snip] > > - we'd better use static linking for most of > > the dlls > > That's what I keep saying ... ;-) This just means: If we use static linking then we don't need to discuss shared libraries. We can just go straight back to the good old DOS days: only static libraries, and every program contains a redundant copy of it. > > automatic > > bug fixing (if you replace the dll you fix > > all programs using this dll). > > 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. This can't be an argument to link doscall1.dll statically or to create a doscall2.dll for the next bugfix, and then doscall3.dll, doscall4.dll, and so on. > BTW, if you _rely_ on libtool-like numbering > (or on numbering like libtool _expects_ it), libtool expects that kind of numbering that has been implemented, i.e., none for DOS, OS/2, and (I guess) also Win*. > you still get the automatic bugfixing, as > that's supposed to be the place where the > third number, that Knut intends to ignore is > supposed to be relevant. Only if the maintainer uses the 3rd digit for the bug fix. Otherwise the program will rely on a buggy dll forever. There is one big difference between OS/2 and Linux. If I compile a program on one OS/2 system using standard OS/2 libraries, then this program will run on all other OS/2 systems providing this library, typically down to OS/2 3.0 or even below. And I have just one copy of every OS/2 dll on my system, and nevertheless, it works. And that's the way it has to be (IMHO). Would you bet that you can compile a program on one Linux system and that it runs on every other Linux system? I don't think so. I heard that you can't exchange executables between different distros (but I haven't tried myself). Great, isn't it? Why is it so? Because Linux people (or many of them) don't care about binary compatibility. They install a full distro, and that's it. Because you can (could) recompile everything (if you have the code). With a new distro you automatically lose the old library versions so that /.../lib keeps clean (in some sense). If you do that for OS/2 you can't exchange programs between different OS/2 installations. Instead, you have to install all possible old dll versions and you can never remove them because there will be ever an old program on hobbes which needs an old version. Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Mon, 12 Jan 2004 23:01:30 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? Andreas Buening wrote: [a far too long mail] If this doesn't convince you, the following might change your mind: Assume, Knut had implemented his 6+2 naming scheme into libtool and is now prepared to do the real world test: compiling GNU gettext. ;-) ;-) Since 0.11 gettext doesn't install only libintl but also two internal helper libraries: libgettextlib and libgettextsrc which are used by the gettext tools only, no other program in the world knows about them. Therefore, the new libtool would install intl0B.dll and also gettex0B.dll and (Oops!) gettex0B.dll. You would need at least 8 significant chars to distinguish both dlls: gettextl.dll and gettexts.dll. Since the libtool logic doesn't provide any knowledge which library gets installed from another source directory of the source tree, it's not possible to implement an automatic mechanism to avoid this kind of naming conflict within a package. Ouch! What you can do, is to implement an OS/2-specific magic, e.g. an env. var. like EMX_LIBTOOL_DLLNAMES="s/gettextsrc/gtsrc0B/;s/gettextlib/gtlib0B/" which is processed somewhere deep in the libtool voodoo code. This also means that it's impossible to get a useful installation of gettext without any kind of intelligence at the other end of the command line. ;-) So we need some kind of maintainer who resolves the naming conflicts manually. Once we've arrived at this stage, why should we implement some code for dll name replacements by using sed _and_ some code to implement some magic naming scheme. Why not use the first one for both? Even better: How can libtool know whether we want a .lib or a .a library? I've implemented a mechanism that uses .a if gcc produces ..o files, and .lib for .obj files. But gcc 3.x produces only .o files by default. grepping $CFLAGS is insufficient to distinguish between a.out and omf since the user might have used CC="gcc options" or CPPFLAGS="-Zomf". The more you think about libtool, the more difficult the problem becomes. :-( Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Tue, 13 Jan 2004 12:38:23 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: Any new UX2BS testers? 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... > 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? > the other systems use *.so files which > are symbolic links to *.so.1 files (in some cases also .2 > up to .7). > And these files are real. I assume, these numbers specify > the > release according to binary compatibility. That's at least what libtool intends them to be, yes. On Linux x is relevant, y may be relevant, z is irrelevant (just a release number expected to indicate no changes in interface) > So, yes, if we're talking about C++ > and if a library is supposed to work on different > computers, > then static linking should be used, IMHO. Again, I don't expect a whole lot of diffenrent incompatible compiler versions to be used in future, especially when it comes to C++ there isn't that much choice on OS/2. So I wouldn't say that C++ always has to be linked statically. > No, it is NOT good. Taking alone the discussions about > "program > xyz doesn't work because gcc?????.dll is not found. Those really should have been static libs... > Where can I > find this dll?" tells me that you would have to install > lots > of old and crazy dlls for lots of programs. Why is "it doesn't work with intl.dll installed by program uvw" any better? > 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? > 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... > > > - we'd better use static linking for most of > > > the dlls > > > > That's what I keep saying ... ;-) > > 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. 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. > > 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. > This can't be an argument to link doscall1.dll statically > or > to create a doscall2.dll for the next bugfix, and then > doscall3.dll, > doscall4.dll, and so on. Unfortunately, Unix developpers are not at all impressed by the argument that you would have to change DLL name on OS/2 if they applied their change. They just increment their version number and distribute incompatible syscall.so.1, syscall.so.2, syscall.so.3, syscall.so.4. > There is one big difference between OS/2 and Linux. If I > compile > a program on one OS/2 system using standard OS/2 > libraries, then > this program will run on all other OS/2 systems providing > this > library, typically down to OS/2 3.0 or even below. Unless an older version of some DLL ported from Unix land is installed, then it won't run, no matter whether it's a current system or an old one. So for those different, incompatible DLLs, you need different names. > And I > have > just one copy of every OS/2 dll on my system, and > nevertheless, > it works. And that's the way it has to be (IMHO). That's because IBM is exercising much more care in changing DLLs than UNIX developpers put into changing shared objects (those have an "internal" numbering, so you don't need to be that careful, anyway). And you can't hope to teach Unix developpers to developp their shared objects in IBM's way. > Would you bet that you can compile a program on one Linux > system > and that it runs on every other Linux system? I don't > think so. > I heard that you can't exchange executables between > different > distros (but I haven't tried myself). Great, isn't it? If you put some care into compiling, and if you are willing to install some missing libraries (e.g. libc.so.6 in addition to libc.so.5 or vice versa), than you can do that. I'm working for a company that's distributing Linux binaries, so I know what I'm talking about... ;-) > Why is it so? Because Linux people (or many of them) > don't care > about binary compatibility. Exactly. But you want to use the same name for binary incompatible DLLs nonetheless, or what? > If you do that for OS/2 you can't exchange programs > between different > OS/2 installations. Instead, you have to install all > possible old > dll versions and you can never remove them because there > will be ever > an old program on hobbes which needs an old version. I'm sorry, but I still think this is preferable to not being able to run that old program... Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs