On 1/28/09, Jeffrey Hutzelman <jh...@cmu.edu> wrote: > > * 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.
You can configure this via /etc/opensc.conf > > 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). If you have unclean interface, but pcsc-lite has. > 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. You can configure this via /etc/opensc.conf > 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. This was fixed. > Is there some reason I'm not seeing why dynamically loading this library is > better than simply linking against it? The entry points are part of PC/SC spec. The code works the exact way in win32, win64 and POSIX. Regards, Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
