Date: Tue, 13 Jan 2004 00:07:05 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 257 ************************************************** Monday 12 January 2004 Number 257 ************************************************** Subjects for today 1 Re: Any new UX2BS testers? : knut st. osmundsen" 2 Re: Any new UX2BS testers? : Andreas Buening 3 Re: Any new UX2BS testers? : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Sun, 11 Jan 2004 14:36:32 +0100 From: "knut st. osmundsen" Subject: Re: Any new UX2BS testers? Andreas Buening wrote: > knut st. osmundsen wrote: > > [snip] > > >> As for libtool porting, I of course make sure the dll name is no >> more than 8 chars long (incuding any release number stuff). The >> first two numbers in the release string (if present) is appended >> with no dots and not in decimal but 36 digit numbers, 0-9A-Z, to >> save precious space. (Any sugestions about ways to encode a couple >> of numbers in a more condense way is welcome.) > > > I don't like this because - this leads to unreadable DLL names > (foo3243a.dll) - if you have programs linked with different versions > of libfoo, you have to have many foo*.dll on your system, even if > those versions are binary compatible - it doesn't help if the library > name is 8 bytes or longer - if the library name is 6 or 7 byte, I > doubt, you can compress a version string like 1.24.5 into 1 or 2 > bytes (in a unique and automagically working way) I'm not sure if I made it very clear, but I just wanted the first two numbers of the release. Which means 1.24 will be translated to 1R. Since this suffix is added after the name and in uppercase reading the name shouldn't be that much of a problem. For instance you can't say you've got any trouble figuring out that bfd2B.dll is libbfd v2.11. > Therefore, IMHO the best solution would be > > - to use the library name as is, without any release numbers - to > strip (only) the dll name down to 8 characters if necessary - and, if > the 8 char dll name isn't unique (e.g. libverylongnamebar and > libverylongnamefoo would both lead to verylong.dll) or if a new > library version isn't binary compatible with the old version, provide > a way to specify the final dll name by hand: e.g. an env. var. > EMX_LIBTOOL_DLLNAME which overrides the default (verylong.dll). > > Then you wouldn't get a new dll name for every tiny bugfix release. I must say I totally disagree with you here. Release numbers on are usually indicating changes. If I've got it right, change in major number usually means you can forget about being binary compatible with any newer or older release. Changes in the 2nd release number usually also means incompatability although it doesn't have to mean that. Changes in subseqent numbers usually just means bugfixing. So, IMHO it makes sense to encode the two first numbers into the dll name to avoid name clashes with incompatible versions of a library. >> The porting is going slowly (but I've got both DLLs and libs now) >> since I encountered some trouble telling libtool about import >> libraries. One would think the Win32 guys had tought libtool that >> concept years ago, but not. > > > libtool 1.4.x has the concept of import libraries from Win32 > (somewhere). They're created in the .intl subdirectories. I haven't seen that. I think win32 is configuring the static libs to be the inport libs. import libs > [snip] > > >> - shared mode (default): >> 1. libfoo_dll.a >> 2. foo_dll.a >> 3. libfoo.a >> 4. foo.a >> 5. foo.dll >> 6. libfoo_s.a >> 7. foo_s.a > > > [,..] > > Isn't it slightly too complicated? :-) Maybe (it's certainly a pain to implement), but ld (the later incarnations at least) and libtools distiguish between shared and static libs. So, I guess it's time OS/2 moves on to do that too. IIRC mingw32 have been doing this for a while (on win32), only they call import libs ..dll.a. I deceded to use _dll.a instead as there was a semistandard for _s.a already. Kind Regards, knut _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Sun, 11 Jan 2004 17:29:11 +0100 From: Andreas Buening Subject: Re: Any new UX2BS testers? knut st. osmundsen wrote: > > Andreas Buening wrote: > > knut st. osmundsen wrote: [snip] > I'm not sure if I made it very clear, but I just wanted the first two > numbers of the release. Which means 1.24 will be translated to 1R. Since > this suffix is added after the name and in uppercase reading the name > shouldn't be that much of a problem. For instance you can't say you've > got any trouble figuring out that bfd2B.dll is libbfd v2.11. So library names are stripped down to 6 chars. What happens with e.g., 2.57, do you expect an alphabetical overflow? ;-) > > Therefore, IMHO the best solution would be > > > > - to use the library name as is, without any release numbers - to > > strip (only) the dll name down to 8 characters if necessary - and, if > > the 8 char dll name isn't unique (e.g. libverylongnamebar and > > libverylongnamefoo would both lead to verylong.dll) or if a new > > library version isn't binary compatible with the old version, provide > > a way to specify the final dll name by hand: e.g. an env. var. > > EMX_LIBTOOL_DLLNAME which overrides the default (verylong.dll). > > > > Then you wouldn't get a new dll name for every tiny bugfix release. > > I must say I totally disagree with you here. > Release numbers on are usually indicating changes. If I've got it right, > change in major number usually means you can forget about being binary > compatible with any newer or older release. Changes in the 2nd release > number usually also means incompatability although it doesn't have to > mean that. Changes in subseqent numbers usually just means bugfixing. I wouldn't bet on it. I wouldn't even bet that a change in the third number guarantees binary compatibility. Some maintainers don't really care about it. But usually, a new release provides still the same interface, i.e., the same function names (entry points) and the same type and number of arguments. Then the library is backward compatible, and it's sufficient to replace the old one by the new one. There are three changes that can happen with a new release: - new functions, i.e., new entry points to the dll, - new names for existing functions, e.g. to rename do_something() by libxyz_do_something() to keep the global namespace clean, - a really new interface, i.e., do_something() suddenly expects different arguments. The 1st case is no problem since it's backward compatible. This will be the most likely case. The 2nd case would require a manually generated .def file to provide still the old function names to old programs. This won't happen often, typically once per library. The 3rd case is the real bad one. It means that all people using this library have to change their source code to comply to the new interface. Therefore, this won't happen very often. Otherwise the library would be absolutely unreliable and basically unusable. > So, IMHO it makes sense to encode the two first numbers into the dll > name to avoid name clashes with incompatible versions of a library. This leads to zillions of dlls of nearly the same name because everybody uses his own preferred version for linking "his" programs. If we have intl0A.dll, intl0B.dll, intl0C.dll, and so on, then we get - different behaviour of programs depending on which intl??.dll the program is linked to, - great bug reports ("NLS just doesn't work", "I use -lintl but it doesn't link to any intl.dll, what's going on?"), - waste of space and basically chaos in the dll directories - we can never delete any of those stoneage dlls because there will be ever a program that needs them (like the gcc*.dll chaos, but now for ALL dlls), - we'd better use static linking for most of the dlls because otherwise every developer will require other dlls to be installed if I want to run his program, - this is in contradiction to the basic idea of having shared libraries: to save space (the dll is needed only once on your hard disk), automatic bug fixing (if you replace the dll you fix all programs using this dll). I understand that we would need some kind of maintainer who decides whether a new version requires a new dll name but I think it's worth. [snip] > > libtool 1.4.x has the concept of import libraries from Win32 > > (somewhere). They're created in the .intl subdirectories. > > I haven't seen that. I think win32 is configuring the static libs to be > the inport libs. import libs If you use --disable-static, then libtool 1.4.x tries to create dlls, module definition files, import libraries, and so on in the .intl subdirectories. This has been implemented since 1.4.1 or 1.4.2, I guess. If they haven't removed this for 1.5.x, then it's still there. [snip] > Maybe (it's certainly a pain to implement), but ld (the later > incarnations at least) and libtools distiguish between shared and static > libs. So, I guess it's time OS/2 moves on to do that too. IIRC mingw32 > have been doing this for a while (on win32), only they call import libs > .dll.a. I deceded to use _dll.a instead as there was a semistandard for > _s.a already. I still think it's overkill. Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Mon, 12 Jan 2004 11:08:46 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: Any new UX2BS testers? Andreas Buening schrieb: > I wouldn't bet on it. I wouldn't even bet that a change > in the third number > guarantees binary compatibility. Some maintainers don't > really care about it. > But usually, a new release provides still the same > interface, i.e., > the same function names (entry points) and the same type > and number of > arguments. Then the library is backward compatible, and > it's sufficient > to replace the old one by the new one. 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? > - a really new interface, i.e., do_something() suddenly > expects > different arguments. > > The 3rd case is the real bad one. It means that all > people using > this library have to change their source code to comply > to the new > interface. Therefore, this won't happen very often. Actually, adding a new default argument is rather common in C++, it doesn't even require changing existing source, just recompiling and relinking. ;-) > 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. > If we have > intl0A.dll, intl0B.dll, intl0C.dll, and so on, then we > get - working programs! ;-) > - we can never delete any of those stoneage dlls because > there will be > ever a program that needs them (like the gcc*.dll > chaos, but now > for ALL dlls), - On the other hand we can add a new (incompatible) version and link new programs against that one instead of having to stay with the one existing version that will work with existing programs. > - we'd better use static linking for most of > the dlls That's what I keep saying ... ;-) > 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. BTW, if you _rely_ on libtool-like numbering (or on numbering like libtool _expects_ it), 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. Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs