--On Wednesday, January 28, 2009 12:51:05 PM +0200 Alon Bar-Lev <alon.bar...@gmail.com> wrote:
>> 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 Sure, but it shouldn't make a bogus assumption in the first place. >> 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 Again, true, but the default is wrong. >> 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. Since 0.11.6? Apparently so, since I see the version on the trunk includes <winscard.h> if that exists. OK. >> 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. The API is part of the spec. But it is possible for an ABI to stay the same while the API changes. For example, in the case of pcsc-lite this would happen on some architectures if we were to change the definition of DWORD to always be a 32-bit type, as is the case on Windows, rather than being an unsigned long, as it is currently defined both in internal-winscard.h and in the winscard.h shipping with pcsc-lite. Such a change would massively break opensc (but not on 32-bit Linux, where unsigned long is 32 bits, so it might be hard to notice), because the binary interface provided by libpcsclite.so would no longer be the same. But you haven't answered my question, which is... Why is it _better_ to do this explicit dynamic loading of a shared library than to link against it in the normal fashion? I assume there was actually some specific reason for the change, and perhaps we'll hear about it when Andreas has a chance to respond. -- Jeff _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
