1.libtool How did you build libtool? Have you added LTLIB_CFLAGS="-I<>" LTLIB_LIBS="-L<> -lltdl" to configure?
2. mingw runtime should have gettimeofday... Please tell me if it does not work after your update. Thanks! On 2/25/08, Jan Just Keijser <[EMAIL PROTECTED]> wrote: > Hi Alon, > > I already did and continued; turns out that my LIBTOOL setup was/is > still not OK (lots of missing -lltdl lines in the makefiles). After > correcting that one the build continued until pkcs11-global.c, where it > ran into problems with the gettimeofday function that MingW does not > seem to support. The compile error was something about an unknown struct > size: > struct _timeb time_buf; > > At that point I decided to scratch my entire Mingw/Msys setup. I will > re-install MingW+msys tools tomorrow and continue. > > > cheers, > > JJK > > Alon Bar-Lev wrote: > > Hello, > > > > Thank you for testing! > > > > The pkcs15-piv.c should not have included openssl... I guess this is > > leftover from some other work. > > Can you please try to remove these includes and continue building? > > > > Alon. > > > > On 2/25/08, Jan Just Keijser <[EMAIL PROTECTED]> wrote: > > > >> Hi Alon, > >> > >> finally had some time to test your new build system on my Windows XP box > >> with both Cygwin and MingW installed. > >> > >> ./configure + make ran fine on cygwin; the resulting pkcs11-tool (which > >> is all I really use) was working fine > >> ./configure ran on MingW after I added libtool to my MingW installation. > >> make did *not* run on MingW because openssl was missing: > >> > >> /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > >> -I../.. -I../../src/include -I../../src/common -DWIN32_LEAN_AND_MEAN > >> -L/usr/local/include -fno-strict-aliasing -g -O2 -MT pkcs15-piv.lo -MD > >> -MP -MF .deps/pkcs15-piv.Tpo -c -o pkcs15-piv.lo pkcs15-piv.c > >> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/common > >> -DWIN32_LEAN_AND_MEAN -L/usr/local/include -fno-strict-aliasing -g -O2 > >> -MT pkcs15-piv.lo -MD -MP -MF .deps/pkcs15-piv.Tpo -c pkcs15-piv.c > >> -DDLL_EXPORT -DPIC -o .libs/pkcs15-piv.o > >> pkcs15-piv.c:34:25: openssl/bio.h: No such file or directory > >> pkcs15-piv.c:35:25: openssl/rsa.h: No such file or directory > >> pkcs15-piv.c:36:25: openssl/pem.h: No such file or directory > >> > >> So building without openssl support does NOT seem to be supported (which > >> is fine, I guess, it's just that my very minimalistic MingW install has > >> no support for it, nor for readline or zlib). > >> > >> > >> cheers, > >> > >> JJK > >> > >> > >> > >> Alon Bar-Lev wrote: > >> > >> > >>> Hi! > >>> > >> > Waiting for your input :) > >> > Alon > >> > > >> > On 2/14/08, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > >> > > >> >> On Thu, Feb 14, 2008 at 7:01 PM, Martin Paljak <[EMAIL PROTECTED]> > wrote: > >> >> > > 4. openct, pcsc and nsplugins features are disabled by default. > >> >> > I don't think it's a good idea to by default disable most used > reader > >> >> > interfaces by default, as I'd expect most software to behave > nicely > >> >> > after a ./configure; make; make install cycle. Have not tried it > on > >> >> > Linux, but we might include some special handling code for Mac as > Mac > >> >> > is a pretty defined platform. a ./configure; make; make install > cycle > >> >> > could work on osx as well flawlessly. > >> >> > >> >> > >> >> I don't like packages that enable optional features automatically. > >> >> Users/packagers should choose what they wish and enable dependency > explicitly. > >> >> In this case, nsplugin seldom used anyway, and there is not much > sense in > >> >> enabling both pcsc and openct. > >> >> And if the user has for some strange reason openct installed, does > it mean > >> >> the result of OpenSC compilation should depend on it? > >> >> > >> >> I truly think users are able to choose, and I am sure distro > packagers will > >> >> enable the features by the dependency of their packages. > >> >> > >> >> > >> >> > > 9. Add export files to each library in order to export only > required > >> >> > > symbols. Windows native build may use these files instead of > scanning > >> >> > > objects' symbols. > >> >> > I should investigate this. While at it, we could also 'break' the > >> >> > windows build, drop libltdl dependance and have a wrapper that > uses > >> >> > native win32 API calls on windows and libltdl on other platforms. > >> >> > >> >> > >> >> I also think that Windows does not need libltdl... Is there any > reason to > >> >> use it at *NIX? I don't think .la files are used anyway... > >> >> But this change can be done later... > >> >> > >> >> > >> >> > Great work and I hope we can release the next version with a new > build > >> >> > system and other generic improvements :) > >> >> > >> >> > >> >> Thanks! > >> >> Waiting for your test results. > >> >> > >> >> Alon. > >> >> > >> >> > >> > >> > >> > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
