Обсуждение: Re: [pgadmin-hackers] Client-side password encryption
> > > As for Windows DLL hell, I don't know a lot about that, but if > > > that's such a problem, why didn't the original creators of the > > > windows port stick the version number in there from the start. On > > > UNIX, libpq is half versioned (the library is, but not > the symbols) > > > so I would have thought copying that idea would have been obvious. > > > > Because we simply didn't think of it at the time, and it's > something > > that has irked me ever since. > > In that case, I agree. I've always thought a lot of problem > in windows could be solved if they systematically added a > version number to every library (like in UNIX). > > Are there any reasons why we shouldn't change the libname > with every release like for UNIX? I can't think of any, but > you never know... Yes. If FooApp is compiled against 8.0, it will then be unable to run if you upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new version if it's just a minor version upgrade (correct me if I'm wrong). On windows, it will break with an ugly dialog box. Which is why DLL renames are usually only done for backwards incompatible changes. //Magnus
On Mon, Dec 19, 2005 at 01:07:26PM +0100, Magnus Hagander wrote: > If FooApp is compiled against 8.0, it will then be unable to run if you > upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new > version if it's just a minor version upgrade (correct me if I'm wrong). > On windows, it will break with an ugly dialog box. Which is why DLL > renames are usually only done for backwards incompatible changes. Not quite, in UNIX you have a SONAME which is the file you search for at runtime. This might end up being symlinked to a different version than the one you linked against. The argument for the name change is that then you can have both the old version and the new versions installed at the same time. So when you "upgrade" to 8.1, you don't actually remove the old libpq but keep both around. Then programs using either will continue to work. On UNIX you don't actually waste any diskspace because you can symlink them together. So it's only an issue if you have a policy of removing old versions of libpq on upgrades... I'm not sure what's "best practice" on windows in this area. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Martijn van Oosterhout wrote: > > So it's only an issue if you have a policy of removing old versions of > libpq on upgrades... I'm not sure what's "best practice" on windows in > this area. When removing the application (in this case: pgsql), you'd remove that old lib as well if it's the only app using it. If you have another application installed, the deinstaller should observe this, and keep the version. I'm voting +1 for lib name versions. Regards, Andreas
Andreas Pflug wrote: > Martijn van Oosterhout wrote: > > > > > So it's only an issue if you have a policy of removing old versions of > > libpq on upgrades... I'm not sure what's "best practice" on windows in > > this area. > > When removing the application (in this case: pgsql), you'd remove that > old lib as well if it's the only app using it. If you have another > application installed, the deinstaller should observe this, and keep the > version. > > > I'm voting +1 for lib name versions. If you add a version number to the Win32 libpq name, you have to update any command-line compile tools that mention libpq after an upgrade. The Unix linker knows about version numbers, but the Win32 linker doesn't, so adding version numbers does add quite a bit of chaos to the Win32 compile world. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On 12/21/05, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Andreas Pflug wrote: > > Martijn van Oosterhout wrote: > > > > > > > > So it's only an issue if you have a policy of removing old versions of > > > libpq on upgrades... I'm not sure what's "best practice" on windows in > > > this area. > > > > When removing the application (in this case: pgsql), you'd remove that > > old lib as well if it's the only app using it. If you have another > > application installed, the deinstaller should observe this, and keep the > > version. > > > > > > I'm voting +1 for lib name versions. > > If you add a version number to the Win32 libpq name, you have to update > any command-line compile tools that mention libpq after an upgrade. The > Unix linker knows about version numbers, but the Win32 linker doesn't, > so adding version numbers does add quite a bit of chaos to the Win32 > compile world. > win32 compile world *is* a chaos... it's very frustating when you try to run a program and it fails because a library (when you actually has the library, at least _a_ version of the library)... IMHO, adding version numbers to the name of library for windows is a the cleanest thing you can do... > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote: > If you add a version number to the Win32 libpq name, you have to update > any command-line compile tools that mention libpq after an upgrade. The > Unix linker knows about version numbers, but the Win32 linker doesn't, > so adding version numbers does add quite a bit of chaos to the Win32 > compile world. The funny thing about it is that the UNIX linker doesn't know about version numbers at all. It just looks for a lib<libname>.so (no version) which is symlinked to the actual version to use. Thus just by changing a few symlinks you can control which library version is linked in. Delete the .so and the linker won't find the library anymore (and fall back to the .a lib) though runtime users still will find it because they *do* have the version number, which is extracted from the library itself. I'm often impressed by the way UNIX is highly configurable yet trivially transparant at the same time. The chances that anything remotely similar would work on windws seems slim at best. -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote: > > If you add a version number to the Win32 libpq name, you have to update > > any command-line compile tools that mention libpq after an upgrade. The > > Unix linker knows about version numbers, but the Win32 linker doesn't, > > so adding version numbers does add quite a bit of chaos to the Win32 > > compile world. > > The funny thing about it is that the UNIX linker doesn't know about > version numbers at all. It just looks for a lib<libname>.so (no > version) which is symlinked to the actual version to use. Thus just by > changing a few symlinks you can control which library version is linked > in. Delete the .so and the linker won't find the library anymore (and > fall back to the .a lib) though runtime users still will find it > because they *do* have the version number, which is extracted from the > library itself. Yes, important distinction. Thanks for the clarification. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073