OpenSC and multi-arch support

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSC and multi-arch support

Ludovic Rousseau
Hello,

pcsc-lite on Debian and Ubuntu now supports multi-arch [1]. A
multi-arched library is no more stored in /usr/lib/ but in
/usr/lib/x86_64-linux-gnu for amd64 systems and
/usr/lib/i386-linux-gnu for i386 systems (and the same naming applies
for all the other achitectures).

The idea of multi-arch is to be able to have intel 32 and 64 bits
programs and libraries installed at the same time on the same system.

Now the problem with OpenSC.
OpenSC is no more linked with libpcsclite but uses dlopen(3) to load
the library at runtime.
Since the library has moved the dlopen() call fails and the library
can't be found and loaded. See Ubuntu bug #973886 [2].

One solution is to link OpenSC with libpcsclite at compile time. This
is working because the dynamic linker has been modified for multi arch
and knows where to find a library.

Now that OpenCT is deprecated and PC/SC should be the only card
interface to be used maybe  the default could be to link at build
time.

Is anybody modifying the provider_library= configuration in
/etc/opensc.conf to something else than the default value? What is the
use case?

Bye

[1] http://wiki.debian.org/Multiarch
[2] https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/973886

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Frank Morgner
Adjusting the loader to determine the architecture and recognizing
architecture specific directories would be the more generic solution, I
think.  You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
I think the OS should fix this.

On Wednesday, April 11 at 01:46PM, Ludovic Rousseau wrote:

>
> Hello,
>
> pcsc-lite on Debian and Ubuntu now supports multi-arch [1]. A
> multi-arched library is no more stored in /usr/lib/ but in
> /usr/lib/x86_64-linux-gnu for amd64 systems and
> /usr/lib/i386-linux-gnu for i386 systems (and the same naming applies
> for all the other achitectures).
>
> The idea of multi-arch is to be able to have intel 32 and 64 bits
> programs and libraries installed at the same time on the same system.
>
> Now the problem with OpenSC.
> OpenSC is no more linked with libpcsclite but uses dlopen(3) to load
> the library at runtime.
> Since the library has moved the dlopen() call fails and the library
> can't be found and loaded. See Ubuntu bug #973886 [2].
>
> One solution is to link OpenSC with libpcsclite at compile time. This
> is working because the dynamic linker has been modified for multi arch
> and knows where to find a library.
>
> Now that OpenCT is deprecated and PC/SC should be the only card
> interface to be used maybe  the default could be to link at build
> time.
>
> Is anybody modifying the provider_library= configuration in
> /etc/opensc.conf to something else than the default value? What is the
> use case?
>
> Bye
>
> [1] http://wiki.debian.org/Multiarch
> [2] https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/973886
>
> --
>  Dr. Ludovic Rousseau
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--
Frank Morgner

Virtual Smart Card Architecture  http://vsmartcard.sourceforge.net
OpenPACE                         http://openpace.sourceforge.net
IFD Handler for libnfc Devices   http://sourceforge.net/projects/ifdnfc

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Douglas E. Engert


On 4/11/2012 8:16 AM, Frank Morgner wrote:
> Adjusting the loader to determine the architecture and recognizing
> architecture specific directories would be the more generic solution, I
> think.  You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
> I think the OS should fix this.

This would appear to be a common problem with many other packages
using dlopen like pam.


dlopen man page says:
  If filename contains a slash ("/"), then it is interpreted as a
  (relative or absolute) pathname. Otherwise, the dynamic linker
  searches for the library as follows (see ld.so(8) for further details):

So can the default be just "libpcsclite.so"?

>
> On Wednesday, April 11 at 01:46PM, Ludovic Rousseau wrote:
>>
>> Hello,
>>
>> pcsc-lite on Debian and Ubuntu now supports multi-arch [1]. A
>> multi-arched library is no more stored in /usr/lib/ but in
>> /usr/lib/x86_64-linux-gnu for amd64 systems and
>> /usr/lib/i386-linux-gnu for i386 systems (and the same naming applies
>> for all the other achitectures).
>>
>> The idea of multi-arch is to be able to have intel 32 and 64 bits
>> programs and libraries installed at the same time on the same system.
>>
>> Now the problem with OpenSC.
>> OpenSC is no more linked with libpcsclite but uses dlopen(3) to load
>> the library at runtime.
>> Since the library has moved the dlopen() call fails and the library
>> can't be found and loaded. See Ubuntu bug #973886 [2].
>>
>> One solution is to link OpenSC with libpcsclite at compile time. This
>> is working because the dynamic linker has been modified for multi arch
>> and knows where to find a library.
>>
>> Now that OpenCT is deprecated and PC/SC should be the only card
>> interface to be used maybe  the default could be to link at build
>> time.
>>
>> Is anybody modifying the provider_library= configuration in
>> /etc/opensc.conf to something else than the default value? What is the
>> use case?
>>
>> Bye
>>
>> [1] http://wiki.debian.org/Multiarch
>> [2] https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/973886
>>
>> --
>>   Dr. Ludovic Rousseau
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Ludovic Rousseau
Le 11 avril 2012 16:37, Douglas E. Engert <[hidden email]> a écrit :

>
>
> On 4/11/2012 8:16 AM, Frank Morgner wrote:
>> Adjusting the loader to determine the architecture and recognizing
>> architecture specific directories would be the more generic solution, I
>> think.  You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
>> I think the OS should fix this.
>
> This would appear to be a common problem with many other packages
> using dlopen like pam.
>
>
> dlopen man page says:
>  If filename contains a slash ("/"), then it is interpreted as a
>  (relative or absolute) pathname. Otherwise, the dynamic linker
>  searches for the library as follows (see ld.so(8) for further details):
>
> So can the default be just "libpcsclite.so"?

The default is already "libpcsclite.so.1" (do not forget the ".1")
withour any path.

I will try to reproduce the Ubuntu bug.
Maybe the problem is easy to solve.

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Ludovic Rousseau
Le 11 avril 2012 16:43, Ludovic Rousseau <[hidden email]> a écrit :

> Le 11 avril 2012 16:37, Douglas E. Engert <[hidden email]> a écrit :
>>
>>
>> On 4/11/2012 8:16 AM, Frank Morgner wrote:
>>> Adjusting the loader to determine the architecture and recognizing
>>> architecture specific directories would be the more generic solution, I
>>> think.  You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
>>> I think the OS should fix this.
>>
>> This would appear to be a common problem with many other packages
>> using dlopen like pam.
>>
>>
>> dlopen man page says:
>>  If filename contains a slash ("/"), then it is interpreted as a
>>  (relative or absolute) pathname. Otherwise, the dynamic linker
>>  searches for the library as follows (see ld.so(8) for further details):
>>
>> So can the default be just "libpcsclite.so"?
>
> The default is already "libpcsclite.so.1" (do not forget the ".1")
> withour any path.
>
> I will try to reproduce the Ubuntu bug.
> Maybe the problem is easy to solve.

The bug is Ubuntu specific. See [1] for more details.

The Ubuntu OpenSC package has been configured with
--with-pcsc-provider=/lib/libpcsclite.so.1
This is because on Ubuntu libpcsclite.so.1 is/was in /lib and not in
/usr/lib. See [2].
And now, with the multi arch change, the absolute lib filename is wrong.

We have nothing to change on OpenSC. dlopen(3) is doing its job correctly.

Bye

[1] https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/978974
[2] http://ludovicrousseau.blogspot.fr/2010/10/pcsc-lite-upgrade-and-ubuntu-special.html

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Alon Bar-Lev
On Thu, Apr 12, 2012 at 11:12 AM, Ludovic Rousseau
<[hidden email]> wrote:

> Le 11 avril 2012 16:43, Ludovic Rousseau <[hidden email]> a écrit :
>> Le 11 avril 2012 16:37, Douglas E. Engert <[hidden email]> a écrit :
>>>
>>>
>>> On 4/11/2012 8:16 AM, Frank Morgner wrote:
>>>> Adjusting the loader to determine the architecture and recognizing
>>>> architecture specific directories would be the more generic solution, I
>>>> think.  You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
>>>> I think the OS should fix this.
>>>
>>> This would appear to be a common problem with many other packages
>>> using dlopen like pam.
>>>
>>>
>>> dlopen man page says:
>>>  If filename contains a slash ("/"), then it is interpreted as a
>>>  (relative or absolute) pathname. Otherwise, the dynamic linker
>>>  searches for the library as follows (see ld.so(8) for further details):
>>>
>>> So can the default be just "libpcsclite.so"?
>>
>> The default is already "libpcsclite.so.1" (do not forget the ".1")
>> withour any path.
>>
>> I will try to reproduce the Ubuntu bug.
>> Maybe the problem is easy to solve.
>
> The bug is Ubuntu specific. See [1] for more details.
>
> The Ubuntu OpenSC package has been configured with
> --with-pcsc-provider=/lib/libpcsclite.so.1
> This is because on Ubuntu libpcsclite.so.1 is/was in /lib and not in
> /usr/lib. See [2].
> And now, with the multi arch change, the absolute lib filename is wrong.

Right.

>
> We have nothing to change on OpenSC. dlopen(3) is doing its job correctly.


Anyway, now that mingw64 is maintained and I guess the ooooold
pcsc-lite may not be supported any more (the one that broke some
interface), it should be safe to link at compile time, change should
not be significant.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC and multi-arch support

Martin Paljak-4
Hello,
On Sat, Apr 14, 2012 at 19:55, Alon Bar-Lev <[hidden email]> wrote:

> Anyway, now that mingw64 is maintained and I guess the ooooold
> pcsc-lite may not be supported any more (the one that broke some
> interface), it should be safe to link at compile time, change should
> not be significant.

Direct linking was also a necessity on Android for some people, for
reasons I can't remind at the moment.

Martin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel