--On Thursday, July 31, 2008 05:40:40 PM +0200 Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> Changes in OpenSC 0.11.5 released 2008-07-31 > * PC/SC library is dynamic linked no longer compile time dependency. WHY???? What was wrong with using pkg-config to find the library, and then linking against it? This approach is broken in several ways: It assumes the pcsclite library is in a particular location, instead of searching for it. This means it will fail to find libpcsclite on a system where it is installed in /usr/local, for example. Further, the location in question is not derived from $prefix, but rather is hardcoded, which is generally considered to be poor behavior for configure scripts. If you're going to make an assumption, the correct assumption is $libdir, not /usr/lib. It assumes that no particular compiler options or other configuration are required to be compatible with that library, where these would normally be provided by pkg-config (this alone is not such a terrible assumption to make, because it is almost always true, but only _almost_ always. For example, on some platforms, if the library used pthreads and the loading program were not built against the pthreads package, things could break in rather bizarre ways). It loads a library named "libpcsclite.so", which is wrong. That name is reserved to refer to a library used at link time; programs referring to the library should (and do, if you just link instead of using dlopen) always use the library's soname, which in this case is "libpcsclite.so.1". This is important because it allows one to affect what library is used when linking new programs without changing the behavior of existing programs in any way. It also insures that things won't break if a new version of libpcsclite comes along with a different ABI, because that will have a different soname and it will be possible for both versions to be present at the same time. It ignores the headers that go with the pcsclite library, and instead uses a built-in header that may or may not agree with the library in particulars such as the type signatures of the functions provided. It's not possible to get run-time checks of type compatibility in any event, but at least you have a fighting chance if you build against the same headers as the library. Is there some reason I'm not seeing why dynamically loading this library is better than simply linking against it? -- Jeff _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
