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.
See issue9942.
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 /opt/thinlinc/lib64/libpcsclite.so.
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.