On 1/28/09, Jeffrey Hutzelman <jh...@cmu.edu> wrote: > --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.
You can override the default using --with-pcsc-provider= > > > 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. > Again, you can override the default using --with-pcsc-provider= > > > 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. I think trunk. > > > 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. I did answer. The reason is to have the same code in OpenSC that is working in POSIX, Windows. While using mingw and visual C and gcc compilers. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
