Le 06/06/2011 15:31, Martin Paljak a écrit : > Hello, > On May 29, 2011, at 10:05 , Viktor Tarasov wrote: >>>> I have a xulrunner application that uses the old modified version of >>>> opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module >>>> . >>>> Static linking will allow the peaceful cohabitation. >>> I would suggest statically compiling the custom version and using it >>> however you find necessary or combining >> It's not actually possible. > Why not? What is the custom xulrunner application anyway? Given it is > "custom", any set of "customizations" should be possible?
The reasons are mostly 'internals'. The build application procedure is quite complicated, subject of the intense QA testing, and finally is not easy to change. >>> Adding a separate build step to the default makefiles for *building* static >>> binaries in parallel with current ones would be nice and OK. >> Ok. >> >> >> >>> But the MSI script of the installer should be tailored for "most >>> appropriate delivery method for 80% use cases/users" where the current >>> dependency on a central libopensc.dll seems justified to me at least. >> Afaiu, for the customer of PKCS#11 module there is no (beside the size) >> difference if this module is static or not . >> The other dependent libraries are actually statically linked -- OpenSSL, >> zlib, ... > Correct. Because for several reasons (like users of minidriver, mostly), it > is good to install relevant DLL-s into System folder. Having OpenSSL (or > zlib) DLL-s in System folder is a Very Bad Idea to my knowledge, but having a > single OpenSC DLL should be manageable and a reasonable choice. > Thus the current model of separate DLL-s for interfaces (minidriver, pkcs11), > a central DLL for "The Core" (opensc.dll) and utilities using "the core". > > Having a slim installer is IMHO desirable, as is having a minimal set of > installed files (I really wish the "onepin" PKCS#11 module could be removed, > hopefully Firefox/NSS folks will realize what's going on one day, I gave up > explaining or trying to come up with a patch, it also requires GUI changes to > be effective). > > Changing the installer is also possible, but it should follow some reasonable > and consistent style. Just bundling more files does not seem like one. > > Possible options could be: > A: current situation > B: blend between static and dynamic linking inside OpenSC package > - static PKCS#11 > - static Minidriver > - opensc.dll for tools only, in tools folder This would be perfect for me. Can this scheme be adopted as a general and replace the current one ? > C: another blend between static and dynamic linking: > - static PKCS#11 > - opensc.dll used by everything else > D: fully static compilation (not reasonable) > E: other options? > >> But it's not so important -- the second static version of PKCS#11 module >> included into MSI will be sufficient. > Into OpenSC.msi? I don't think that's a good idea. Changing the "setup plan" > for OpenSC would be reasonable though. > Best, > Martin Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
