Someone in the OpenSC project apparently didn't think that normal dynamic linking was fancy enough, so recent versions use dlopen() and dlsym() to set up the connection to PCSC-lite. And those command do not respect LD_LIBRARY_PATH, so our smart card tunneling stops working.
There is a configuration option "provider_library" though that can make opensc open our library. This isn't as elegant though as it provides no room for multi-arch systems, and it means that opensc will no longer work locally on the machine.
We need to document this mess.
Checked this again today on my F11 system. Setting:
provider_library = libpcsclite.so.1
...in /etc/opensc.conf causes it to use /opt/thinlinc/lib/libpcsclite.so, but since this is a 64 bit system, this is wrong. Instead I have to manually set it to
The bug causing this is in libtool (which opensc uses). Unlike dlopen(), lt_dlopen() will try to open the first matching library it finds and then give up. So when it fails to load the 32-bit one, it won't continue and try the 64-bit version.
Our solution to this is changing the order of the paths in our LD_LIBRARY_PATH. This will make it work for almost all cases as a 64-bit system will find the 64-bit libpcsctun, and a 32-bit system won't have the lib64 version to cause problems.
When solving this, make sure we test https://www.cendio.com/bugzilla/show_bug.cgi?id=2736 at the same time.
Fixed in r27045.
Whiteboard includes time spent testing bug 2736 and investigating a pcsctun regression (bug 4593, bug 4510).
Works fine on RHEL6.