From: Ralf W. <Ral...@gm...> - 2008-06-01 07:30:17
|
* Roumen Petrov wrote on Sun, Jun 01, 2008 at 01:45:04AM CEST: > My first reply was on following sentence from Erik de Castro Lopo: > =============== > This is a library that was born on Unix and stick rock solid > to the Unix libname.so.X.Y.Z conventions. On windows, this > becomes libname-X.dll. > =============== Yes. But I think you are still misunderstanding how things work on Unices. On Linux, as an example, there are typically symlinks libname.so and libname.so.X to libname.so.X.Y.Z, too. The former is so that newly linked programs pick up the newest library with the soname of libname.so.X, the second is that the runtime linker finds dependent libraries by their soname. The soname is the important thing, and that is libname.so.X under Linux, not libname.s.X.Y.Z. So it helps you nothing that you can have several libraries installed with different Y and Z, you *still* have to take care that the newest one is the one pointed to by libname.so.X. FWIW, I'm specifically saying Linux here, because the details do differ on many other unices; FWIW2, I apologize for having to bring up this slightly off-topic discourse here. > I would like just to point that mingw underling operating system don't > support "rock solid" library versioning system itself and do not expect > that libtool will resolve this issue. > From the quoted text above I assume that library is build with > -version-info option(argument) passed to libtool. There is absolutely no issue with the library naming scheme on w32 *if* you stick to the policy of always installing the *newest* such lib under the name libname-X.dll. That's really no bit different under Unix, either. > So "where to install a dll" is very good question and we may continue > mail thread in direction "mingw package system". Good idea. Please keep in mind that a packaging system is exactly the right place to execute the policy of always having the newest of a compatible library installed. Cheers, Ralf |