* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:08:47AM CEST: > I still don't understand why the developer cannot make the decision if > it is proper or not. > The -static-libtool-libs can be used for this as-well. If it absent > (default) current behavior apply, but if it is specify on shared > library then it should behave consistently with executable.
But programs are (conceptually) different in this respect from libraries: you cannot generate entities which are derived from programs. This means that, whether they incorporate some code from a static library, or link against some shared library, doesn't cause future breakage for files that haven't already entered the dependency tree. > It is usable when you want to provide a library to target with low > space, and your library use a dependency and you don't want the whole > .so be needed at target. Understood. > Or we have in OpenSC issue with Windows, we would like the PKCS#11 > provider (dll) to be without certain dependencies, so that it may be > loaded to application with incompatible OpenSSL reference. Understood as well. These cases sound like small optimizations that have the potential to break things later on for third-party packages using your libraries, if they are not very careful. That's the reason for making it hard to realize in your packages. Example: I would like to create a program that links against your PKCS#11 provider DLL, and for some reason, I also need to link against OpenSSL or some other library from which you have put code into the DLL. If I understand your example above correctly, then I can get into trouble with symbol mixups caused by that. This would not happen, had you linked against the OpenSSL/other DLL in the first place. I hope this helps somehow. I'm not sure how to make this any clearer. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
