On 11/01/2009 04:43 PM, Andreas Jellinghaus wrote:
> Am Sonntag 01 November 2009 13:06:49 schrieb Peter Stuge:
>> Kalev Lember wrote:
>>> I think the correct fix here would be in configure.ac:
>>> -DEFAULT_PCSC_PROVIDER="/usr/lib${libdir##*/lib}/libpcsclite.so.1"
>>> +DEFAULT_PCSC_PROVIDER="libpcsclite.so.1"
>>>
>>> One shouldn't make assumptions in what directory libpcsclite.so.1 is
>>> installed.
>>
>> I agree, -rpath is horrible.
>
> but this discussion isn't about rpath. we are leading the shared
> library as plugin.Yes, it's not rpath here but rather telling dlopen() where exactly the lib is located. But in any case if we don't specify a path, dlopen() will search for "libpcsclite.so.1" in default lib directories (usually /lib and /usr/lib in that order). I don't think it'd make sense to hardcode a path in here, but rather rely on dlopen()'s behaviour to find the right lib. I'd change the default provider to "libpcsclite.so.1" (without path). > well, maybe we shouldn't or at least by default not do that. > alon was working on an alternative implementation and thus > made it easy to configure, which library for the same > static interface is loaded. while this is real nice for developers, > it creates confusion for normal users without this need. > > I don't want to create a new 0.11 release, as editing a config > file or using different configure options is easy. but what is > the best suggestion for distributions? Well, opensc's default currently does not matter much for distributions, because most of them are already specifying pcsc provider through configure options (opensc's old default didn't work at all). In long term, however, the change might do good. Fedora already switched to "libpcsclite.so.1" without path as default provider [1]. If we changed opensc's default to use no path, it'd make life easier for Debian and Ubuntu packages too. In Debian and Ubuntu libpcsclite gets installed in different directories, which means that their opensc packaging also differes. With us changing the default to a sane value, those two distros might be able to merge their opensc packaging differences. [1] http://cvs.fedoraproject.org/viewvc/rpms/opensc/devel/opensc.spec?r1=1.49&r2=1.50 -- Kalev Lember _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
