forwarded 531592 http://w1.fi/bugz/show_bug.cgi?id=315
thank
Colin Watson a écrit :
On Fri, Jun 05, 2009 at 10:17:52PM +0200, Ludovic Rousseau wrote:
Colin Watson a écrit :
We currently ship wpa_supplicant in /sbin so that it can be used early
in the boot process. However, it links against libpcsclite.so.1 which is
in /usr/lib. This breaks things for people with a separate /usr.
Would you consent to moving this library to /lib? The attached patch
implements this change.
I don't think that is the correct solution to the problem.
Moving the library to /lib will allow moving wpa_supplicant in /sbin but
wpa_supplicant will not be able to work with smart card support.
libpcsclite needs to communicate with the pcscd daemon. This daemon is
in /usr/sbin/ and is linked with libhal (and other libs). I don't think
you plan to move libhal (and its dependencies) in /lib.
The correct way to solve this problem is to use dlopen() in
wpa_supplicant and use libpcsclite.so.1 only when needed/requested.
Surely whichever way you slice it you can't talk to pcscd until /usr is
mounted. Does it really matter for this whether wpa_supplicant dlopens
libpcsclite.so.1 when it needs it and starts talking to pcscd then, or
whether it links against it directly and calls into it when it needs it
and starts talking to pcscd then? Unless libpcsclite.so.1 tries to
communicate with pcscd as soon as any binary that happens to link
against it is loaded, which I don't believe to be the case, I don't see
a meaningful difference here. Given that, direct dynamic linking is
clearly simpler than dlopen.
Yes, my proposal will not make wpa_supplicant work with smart card
support if pcscd is not started.
Yes, direct linking is simpler than using dlopen.
My proposal is to have wpa_supplicant in /usr and avoid moving
libpcsclite.so.1 around.
You should have a look at the Ubuntu bug 378294 [1] "libpcsclite1 is not
found by sun-java-6 (jaunty)". Some software do not expect to find a
library in /lib. And yes it is a bug in the Sun JVM. SUN is working on it.
I'm not suggesting that the whole thing be made to work entirely without
/usr. I'm merely suggesting that it would be useful to be able to *start
up* wpa_supplicant without /usr, to simplify some ordering concerns;
/usr is likely to be mounted very shortly afterwards anyway. Once /usr
is mounted, wpa_supplicant should have no problem working with smart
card support.
I completely agree with that.
I looked at the wpa_supplicant code and the needed code is already
present. It is in the file wpasupplicant-0.6.9/src/utils/pcsc_funcs.c
Dynamic loading is used in case of __MINGW32_VERSION. I include a simple
patch to use loading at runtime even on Linux.
I have not tested the patch. I have just tested that the compilation
works and that the resulting binary is no more linked with
libpcsclite.so.1.
I think this bug should be reassigned to wpasupplicant, and my patch
sent to wpasupplicant upstream for review.
You don't say it clearly, but if I'm understanding you correctly you're
essentially also suggesting that wpa_supplicant shouldn't be in /sbin at
all.
No, I am not suggesting to move wpa_supplicant.
Have you looked at the patch I propose?
Bye
[1] https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/378294
--
Dr. Ludovic Rousseau
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
