Hello list, I just found a very stupid bug introduced (by me) in 1.2.0-rc1. A new release candidate is available [1].
I also separated libpcsclite code from musclecard code. A new library libmusclecard is now created and shall be used by applications using musclecard functions. Now we have a clear distinction between functions to access a smart card (libpcsclite) and functions to access a muscle card (libmusclecard). Thanks to Damien Sauveron for the idea. It will break applications linked with libpcsclite and using mucslecard calls. Such applications need to be relinked. But these applications were in a dangerous situation since it was not clear if libpcsclite included or not musclecard functions since it was a ./configure compile time option. So these applications would also fail if pcsclite was not compiled with musclecard support. Maybe I should change the library .so major number but this would break applications using pcsclite only functions. What do you think? Changes: pcsc-lite-1.2.0-rc2: Ludovic Rousseau 4 September, 2003 - removed a very _stupid_ bug that linked libpcsclite with libusb. Any application linked with libpcsclite was also linked with libusb. - generate a new library libmusclecard and remove musclecard code from libpcsclite. An application using musclecard function need to explicitely link with libmusclecard. - src/winscard_clnt.c: add a new function SCardUnload() to free allocated resources. It is mandatory only if you use dlopen/dlclose to often load/unload the library. Otherwi se you will exhaust the ressources available and get a crash. Thanks to Guy Moreillon for the patch. - src/muscletest.c: code cleaning Regards, [1] https://alioth.debian.org/project/showfiles.php?group_id=1225 -- Dr. Ludovic Rousseau [EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
