[Botan-devel] Modularisation and other changes
lloyd at randombit.net
Tue Sep 30 23:36:46 EDT 2008
On Wed, Oct 01, 2008 at 11:29:26AM +0800, Joel Low wrote:
> I've just updated my sources to be 1.7.15, and I've noted a few things.
> * Dependency of TR1. Under Windows VC doesn't have it (well,
> they do, but you must own VC2008 standard++, and I don't J), and I think
> I will have to use the Boost TR1 library. Perhaps this can be noted?
> o Botan\vc\build\include\botan/gfp_element.h(17) : fatal error C1083:
> Cannot open include file: 'tr1/memory': No such file or directory
Yes, InSiTo (whence comes the ECC/GF(p) code) uses tr1. I removed
almost all of the tr1 uses but some remain in the GF(p) math. I plan
to remove them prior all to the next release, but they are indeed
there for the moment. I'm actually a bit torn about that because
shared_ptr would be a very handy thing to have generally.
As to the implementation, Boost TR1
work as a replacement. The only thing that is being used (AFAIK) is
> * __declspec(dllexport). I wrote the changes for the classes to
> build dynamically under Windows, and in build.h there's these few lines
> #ifndef BOTAN_DLL
> #define BOTAN_DLL __declspec(dllexport)
Indeed. I think there are still some configure-y bits you sent me that
have not been applied, but at least all classes are marked with
BOTAN_DLL and IIRC at least some of the configure.pl/nmake changes
were also applied. I've tested the visibilty handling with GCC's ELF
visibility attributes and everything seems to work as expected.
> o I reckon it should be Import not Export because build.h is always
> included. During a library usage (ie when #include <botan/botan.h>) the
> compiler assumes that we're BUILDING Botan and not using it, so declares
> all classes dllexport. This, of course will result in a linker error.
Ah, oops. So it should be dllimport when building the library and
dllexport the rest of the time? Or just dllexport always?
More information about the botan-devel