Re: [Monotone-devel] botan 1.7.3

[Markus Schiltknecht]

Hello Zack,

I've just started to play around with both variants. Again, I've quickly 
given up trying to include the amd64 specific assembler code into our 
Makefile.am. I just didn't feel like duplicating all that build script 
magic, especially as I'm not exactly an autoconf/automake guru.

Thus, I've also tried the other approach: adding a --with-system-botan. 
That was surprisingly straight forward. Please see revision

f508410fff79cdd69fb77d248791abc99f344dcb address@hidden 
2008-02-17T16:13:10 net.venge.monotone.botan.system-switch

You can pull that from my server nabagan.bluegap.ch.

Zack Weinberg wrote:
> I've been thinking about this a bit myself, because the Debian
> security people would really like us to stop using *all* of our
> bundled libraries, so that when a security issue hits one of them they
> can just upgrade the shared library and be done.

Another nice point for using shared libraries, yes.

> Also, hardcoding the configuration parameters for all the bundled
> libraries doesn't just preclude use of Botan engines, it was the
> proximate cause of some 64-bitness headaches with sqlite a while back
> and a weird Windows issue with pcre that I still don't really
> understand.  It would be nice to incorporate the upstream build
> systems (and testsuites!) for the bundled libraries.

Hm.. and then, i.e. calling botan's own configure.pl during our own 
configure run? That could work, although it sounds like a lot of trouble 
as well.

> The vague plan I've got is to give each bundled library a top-level
> directory which contains as near as possible a verbatim import of the
> most recent upstream tarball.  Our own source code moves to a
> subdirectory, and there's a top-level configure script that
> coordinates building all the bundles that are not overridden by
> --with-system-foo, then our own code.  This lets us use -I switches to
> reference the headers for only those bundled libraries we're actually
> using.  [Right now, for instance, I think we're getting the bundled
> pcre.h even if we don't use the bundled library.]

Yeah, I've run into the very same problem with botan. Solved it by 
moving botan/* to botan/botan/*, which was the quickest solution, but 
really isn't that nice.

There are still some problems I'm investigating on. Seems like botan 
1.7.3 is having trouble on ia32.

Also note, that the m4 script is still lacking. However, I can run some 
benchmarks, to check if it's worth the effort. Here are some results, 
all compiled with -O2, the asm optimization is the one linked against 
the (debian) system provided botan (1.7.2, notably), while the other one 
is plain C++ code from the provided botan 1.7.3:

My work machine, a Core 2 Duo:
amd64 c++: 144.93 MiB/s
amd64 asm: 156.25 MiB/s   (7.8% increased throughput)

My laptop, a Core (1) Duo:
ia32 c++: 90.90 MiB/s
ia32 asm: 98.03 MiB/s   (7.8% increased throughput, too)

It would be interesting to test on an AMD machine as well.

Note, that there's no relevant difference in botan's SHA1 code between 
1.7.2 and 1.7.3, so that really shouldn't matter. Quick testing also 
gave the same results.

Regards

Markus