Single-Makefile Build Experiment report

[Mike Bland]

I'm happy to report early, promising success in my Makefile
refactoring experiment. Here's the short link to the Google Doc
containing all of the details:

http://goo.gl/yhvCno

Feedback welcome. Regardless of the ultimate judgment of the
experiment, I'm hoping to build upon this report and produce a
published article.

The bad news: In the end, despite my best efforts to maintain
compatibility with BSDmake, I hit a roadblock (the absence of pattern
rules) that led me to put it aside and complete the experiment using
GNU make.

The good news: GNU make, to the best of my knowledge, is available on
every platform OpenSSL supports. That, and I did manage to maintain
compatibility up until very late in the experiment. There may be ways
of supporting both make flavors, but they’ll likely require keeping
all the extra {GNU,BSD}makefiles and introducing more grottiness into
the Makefiles themselves.

My questions to Ben and Geoff in particular, and the core OpenSSL
maintainers in general:

- Do these results provide acceptable justification for adopting this structure?

- Should I do whatever necessary to support BSD make or will mandating
GNU make as a build requirement be acceptable?

Thanks,

Mike

[Jeffrey Walton]

On Mon, Aug 11, 2014 at 1:00 PM, Mike Bland <mbl...@acm.org> wrote:
> I'm happy to report early, promising success in my Makefile
> refactoring experiment. Here's the short link to the Google Doc
> containing all of the details:
>
> http://goo.gl/yhvCno
>
> Feedback welcome. Regardless of the ultimate judgment of the
> experiment, I'm hoping to build upon this report and produce a
> published article.

Related: Recursive Make Considered Harmful,
http://aegis.sourceforge.net/auug97.pdf.

> The bad news: In the end, despite my best efforts to maintain
> compatibility with BSDmake, I hit a roadblock (the absence of pattern
> rules) that led me to put it aside and complete the experiment using
> GNU make.

Expected. I've written a few cross-platform libraries. Cross-platform
testing is the best way I know to ensure portable code. Speaking from
experience, I wouldn't waste time trying to support Posix make. Just
require Gmake and be done with it.

> The good news: GNU make, to the best of my knowledge, is available on
> every platform OpenSSL supports. That, and I did manage to maintain
> compatibility up until very late in the experiment.

Posix Make is anemic. I believe the work around is to use a portable
make like Gmake.

I don't think the OpenSSL developers agree. In the past, one of the
devs kept telling me "no, its not portable". Your mileage may vary.

> There may be ways
> of supporting both make flavors, but they’ll likely require keeping
> all the extra {GNU,BSD}makefiles and introducing more grottiness into
> the Makefiles themselves.

Do you mean supporting both from a single makefile? Supporting both
essentially means support the most anemic or least featured. I think
you have that now.

> - Should I do whatever necessary to support BSD make or will mandating
> GNU make as a build requirement be acceptable?

The BSDs know Make sucks. The even document the needs for other
make's: http://www.freebsd.org/doc/en/books/porters-handbook/building.html.

Remember, it not just OpenSSL that needs it - a number of other
libraries need it. So its not a "one off" exception for OpenSSL.

Jeff

[Mike Bland]

On Mon, Aug 11, 2014 at 1:22 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
> On Mon, Aug 11, 2014 at 1:00 PM, Mike Bland <mbl...@acm.org> wrote:
>> I'm happy to report early, promising success in my Makefile
>> refactoring experiment. Here's the short link to the Google Doc
>> containing all of the details:
>>
>> http://goo.gl/yhvCno
>>
>> Feedback welcome. Regardless of the ultimate judgment of the
>> experiment, I'm hoping to build upon this report and produce a
>> published article.
> Related: Recursive Make Considered Harmful,
> http://aegis.sourceforge.net/auug97.pdf.

Referred and linked to from the "Motivation" portion of the article.

>> The bad news: In the end, despite my best efforts to maintain
>> compatibility with BSDmake, I hit a roadblock (the absence of pattern
>> rules) that led me to put it aside and complete the experiment using
>> GNU make.
> Expected. I've written a few cross-platform libraries. Cross-platform
> testing is the best way I know to ensure portable code. Speaking from
> experience, I wouldn't waste time trying to support Posix make. Just
> require Gmake and be done with it.
>
>> The good news: GNU make, to the best of my knowledge, is available on
>> every platform OpenSSL supports. That, and I did manage to maintain
>> compatibility up until very late in the experiment.
> Posix Make is anemic. I believe the work around is to use a portable
> make like Gmake.
>
> I don't think the OpenSSL developers agree. In the past, one of the
> devs kept telling me "no, its not portable". Your mileage may vary.
>
>> There may be ways
>> of supporting both make flavors, but they’ll likely require keeping
>> all the extra {GNU,BSD}makefiles and introducing more grottiness into
>> the Makefiles themselves.
> Do you mean supporting both from a single makefile? Supporting both
> essentially means support the most anemic or least featured. I think
> you have that now.

I mean supporting both using *three* Makefiles per directory as
described in the article and posted to my "makefiles" branch on
GitHub.

>> - Should I do whatever necessary to support BSD make or will mandating
>> GNU make as a build requirement be acceptable?
> The BSDs know Make sucks. The even document the needs for other
> make's: http://www.freebsd.org/doc/en/books/porters-handbook/building.html.
>
> Remember, it not just OpenSSL that needs it - a number of other
> libraries need it. So its not a "one off" exception for OpenSSL.

Hopefully, with code and data in-hand, we can have a meaningful
discussion around this, and produce a publishable article describing
whatever choice is eventually made. I imagine such an artifact could
prove useful to other projects.

Mike

[Jeffrey Walton]

On Mon, Aug 11, 2014 at 1:30 PM, Mike Bland <mbl...@acm.org> wrote:
> On Mon, Aug 11, 2014 at 1:22 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
>> On Mon, Aug 11, 2014 at 1:00 PM, Mike Bland <mbl...@acm.org> wrote:
>>> I'm happy to report early, promising success in my Makefile
>>> refactoring experiment. Here's the short link to the Google Doc
>>> containing all of the details:
>>>
>>> http://goo.gl/yhvCno
>>>
>>> Feedback welcome. Regardless of the ultimate judgment of the
>>> experiment, I'm hoping to build upon this report and produce a
>>> published article.
>> Related: Recursive Make Considered Harmful,
>> http://aegis.sourceforge.net/auug97.pdf.
>
> Referred and linked to from the "Motivation" portion of the article.

My bad. I only read the Abstract at the time. Sorry about that.

Google Drive kept telling me there was an error, and asked that I
reload the document (multiple times). You can see an image here:
http://postimg.org/image/vacuxe3cv/7c747a22/.

>>> ...

>>> There may be ways
>>> of supporting both make flavors, but they’ll likely require keeping
>>> all the extra {GNU,BSD}makefiles and introducing more grottiness into
>>> the Makefiles themselves.
>> Do you mean supporting both from a single makefile? Supporting both
>> essentially means support the most anemic or least featured. I think
>> you have that now.
>
> I mean supporting both using *three* Makefiles per directory as
> described in the article and posted to my "makefiles" branch on
> GitHub.

Well, my personal taste would be to supply one makefile named
GNUmakefile. Because OpenSSL has existing gear vis-à-vis Makefile,
then that means two.

I don't think I would worry about the third. Your GNUmakefile has
everything needed for the BSDs when Gmake is installed. There's even a
port for it, so I don't believe there are any hardships requiring
Gmake. For example:

* http://www.openbsd.org/4.5_packages/sh/gmake-3.81p0.tgz-long.html
* http://www.freebsd.org/ports/devel.html#gmake-3.82_1
* http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/gmake/README.html

What I'm not clear on: how about some of the more obscure platforms
that OpenSSL attempts to support?

>>> - Should I do whatever necessary to support BSD make or will mandating
>>> GNU make as a build requirement be acceptable?
>> The BSDs know Make sucks. The even document the needs for other
>> make's: http://www.freebsd.org/doc/en/books/porters-handbook/building.html.
>>
>> Remember, it not just OpenSSL that needs it - a number of other
>> libraries need it. So its not a "one off" exception for OpenSSL.
>
> Hopefully, with code and data in-hand, we can have a meaningful
> discussion around this, and produce a publishable article describing
> whatever choice is eventually made. I imagine such an artifact could
> prove useful to other projects.

OK, good luck. I think there's a lot of good suggestions. Hopefully
some or all will be uptaken.

Related (regarding the issue on Arch Linux and `make clean`): You also have:

make clean && make dclean

That's what I use when testing changes before I switch to a fresh VM
for a clean room. I also remove the distro's 'openssl-devel' or
'libssl-dev' to ensure existing headers are not tainting my
experimental build.

Related: config/configure suck because it essentially ignores our
changes to make's implicit variables
(http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html).
We should *not* need to add a separate configure line for minor
changes like -O3 -> -Os (for mobile platforms), or like Ben's Clang
build (for sanitizers). OpenSSL's build system should honor our flags
and switches.

Jeff

[Didier Cruette]

Hello Mike

Can you give us pointers to ftp repo of this branch, I'll run jenkins on it for windows, linux, Raspberry and so on

Thanks

[Mike Bland]

GitHub and all other relevant links are in the doc. I wouldn't recommend setting up CI for it, though. I rebase my working branches all the time.

Mike

--
http://wiki.openssl.org/index.php/Unit_Testing
---
You received this message because you are subscribed to the Google Groups "openssl-testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-testi...@googlegroups.com.
To post to this group, send email to openssl...@googlegroups.com.
Visit this group at http://groups.google.com/group/openssl-testing.
To view this discussion on the web visit https://groups.google.com/d/msgid/openssl-testing/ff26faf6-9a52-4441-b438-e0aee4e363ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Typanski]

Hey Mike,

I updated my build statistics to include full builds without ccache.
It's the same link as before. I wasn't sure if I should ping the
openssl-dev thread about that, but I'll hold off on the matter for now
since some of this is unrelated.

Just spending all that time building the code repeatedly and
experimenting with how the two systems reacted to touching files,
doing ./configure repeatedly, etc. has helped me get a grasp on what
OpenSSL's actually doing when you build it.

My general thoughts on it all: the old system is a mess. I found the
upstream tree frustrating and hard to work with. When I started
experimenting with breaking the heartbeat code and seeing how that
impacted your unit tests, I got frustrated by it not detecting
changes. The fact that I could go in and change the "payload" (holy
god, it's a payload *length*, not a payload) and run "make test" and
everything passes is just infuriating.

So I really, *really* hope your changes make it in. Because it will
lower the barrier to entry for unit tests, and if I have learned
anything as a developer (saying that makes me question myself ... I
still know less than I'd like) then it's that the barrier to entry for
unit testing should be as low as you can possibly make it.

Rust (Mozilla's language) solves this with the convention of literally
placing tests at the bottom of source files (and compiling them out by
default). I'm not saying OpenSSL should do that, but the point is this
lowers the barrier to entry: you don't even have to open a new file.

Second: I think we should document that -DOPENSSL_NO_UNIT_TEST has to
be removed from the configure script/makefiles to do unit tests. I
didn't realize that back when I wrote a 3-line Travis-CI build for
OpenSSL ... is there a way I can enable the unit tests without just
running sed on the Configure script?

Am I just being stupid? Is there an easier way to enable the tests?

Nathan

[Mike Bland]

Hey Nathan,

Responses inline.

On Thu, Aug 21, 2014 at 1:51 AM, Nathan Typanski <ntyp...@acm.org> wrote:
> Hey Mike,
>
> I updated my build statistics to include full builds without ccache.
> It's the same link as before. I wasn't sure if I should ping the
> openssl-dev thread about that, but I'll hold off on the matter for now
> since some of this is unrelated.

Thanks for doing all this work to reproduce and extend my results.
(For handy reference in this thread: http://goo.gl/zXoniR). If I could
trouble you, could you also do a non-ccache parallel build? No rush,
of course.

> Just spending all that time building the code repeatedly and
> experimenting with how the two systems reacted to touching files,
> doing ./configure repeatedly, etc. has helped me get a grasp on what
> OpenSSL's actually doing when you build it.
>
> My general thoughts on it all: the old system is a mess. I found the
> upstream tree frustrating and hard to work with. When I started
> experimenting with breaking the heartbeat code and seeing how that
> impacted your unit tests, I got frustrated by it not detecting
> changes. The fact that I could go in and change the "payload" (holy
> god, it's a payload *length*, not a payload) and run "make test" and
> everything passes is just infuriating.
>
> So I really, *really* hope your changes make it in. Because it will
> lower the barrier to entry for unit tests, and if I have learned
> anything as a developer (saying that makes me question myself ... I
> still know less than I'd like) then it's that the barrier to entry for
> unit testing should be as low as you can possibly make it.

Sounds like you went through the exact same process I did that led me
to undertake the task in the first place, and reached the exact same
conclusions.

> Rust (Mozilla's language) solves this with the convention of literally
> placing tests at the bottom of source files (and compiling them out by
> default). I'm not saying OpenSSL should do that, but the point is this
> lowers the barrier to entry: you don't even have to open a new file.

I still need to check out Rust. It's an interesting idea, though in C,
we'd have to #ifdef out any test code so's not to bloat the production
library with it. I'm hoping to get a little test generator checked in
one of these days; in the meanwhile, I've just fleshed out this bit of
documentation:

http://wiki.openssl.org/index.php/How_To_Write_Unit_Tests_For_OpenSSL#Create_a_new_test_file_using_the_test_template

> Second: I think we should document that -DOPENSSL_NO_UNIT_TEST has to
> be removed from the configure script/makefiles to do unit tests. I
> didn't realize that back when I wrote a 3-line Travis-CI build for
> OpenSSL ... is there a way I can enable the unit tests without just
> running sed on the Configure script?
>
> Am I just being stupid? Is there an easier way to enable the tests?

Not stupid at all; a little-known change that Steve Henson checked in
a couple weeks ago introduced the 'enable-unit-test' config parameter.
I've documented it here after that change went in, but it's easy to
miss:

http://wiki.openssl.org/index.php/How_To_Write_Unit_Tests_For_OpenSSL#Building_and_Running_the_Test

Here's Steve's change:

https://github.com/openssl/openssl/commit/e0fc7961c4fbd27577fb519d9aea2dc788742715

I'll see if I can start getting some traction on getting my
single-Makefile changes in.

Mike

[Mike Bland]

Just issued pull request #160:

https://github.com/openssl/openssl/pull/160

Will update the thread with the RT issue number when it comes through.

Mike

[Nathan Typanski]

On 08/21, Mike Bland wrote:
> Thanks for doing all this work to reproduce and extend my results.
> (For handy reference in this thread: http://goo.gl/zXoniR). If I could
> trouble you, could you also do a non-ccache parallel build? No rush,
> of course.

Full parallel build is out now.

On my machine you've cut the build time by 32 seconds. That's a 40%
reduction in build time.

Good job.

Nathan

[Didier Cruette]

Hi to all

For the current mbland/opensl/build branch on jenkins CI :

- build + test on linux works well
- build fails on windows mingw :

perl ./Configure mingw enable-unit-test 
Configuring for mingw
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
    no-shared       [default] 
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-store        [experimental] OPENSSL_NO_STORE (skip dir)
    no-zlib         [default] 
    no-zlib-dynamic [default] 
IsMK1MF=0
CC            =gcc
CFLAG         =-DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
EX_LIBS       =-lws2_32 -lgdi32 -lcrypt32
CPUID_OBJ     =x86cpuid.o
BN_ASM        =bn-586.o co-586.o x86-mont.o x86-gf2m.o
DES_ENC       =des-586.o crypt586.o
AES_ENC       =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC        =bf-586.o
CAST_ENC      =cast-586.o
RC4_ENC       =rc4-586.o
RC5_ENC       =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC      =cmll-x86.o
MODES_OBJ     =ghash-x86.o
ENGINES_OBJ   =e_padlock-x86.o
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =\LogicielDeBaseQcr\Git\Git\bin\/perl.exe
THIRTY_TWO_BIT mode
DES_PTR used
DES_RISC1 used
DES_UNROLL used
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined
      0 [main] perl 2344 open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
make: *** [links] Error 255
make  links gentests failed at ./Configure line 2043.


There is a mix between the env path and the perl.exe
On the master branch the reference is 
PERL          =perl

Thanks
Didier

[Ben Laurie]

Hmm. My own single Makefile parallel build is (I think, I'll have to
re-test) about 5x the speed of a standard build, so this is a little
disappointing.

FWIW, I am currently sitting at SFO on my way home, so I hope I'll be
able to pay some more attention to this soon.

>
> Good job.
>
> Nathan

>
> --
> http://wiki.openssl.org/index.php/Unit_Testing
> ---
> You received this message because you are subscribed to the Google Groups "openssl-testing" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openssl-testi...@googlegroups.com.
> To post to this group, send email to openssl...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openssl-testing.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openssl-testing/20140822053947.GA12412%40gmail.com.

[Mike Bland]

[Forgot to reply-all the first time.]

On Aug 23, 2014 6:11 PM, "Ben Laurie" <b...@links.org> wrote:
>
> On 21 August 2014 22:39, Nathan Typanski <ntyp...@gmail.com> wrote:
> > On 08/21, Mike Bland wrote:
> >> Thanks for doing all this work to reproduce and extend my results.
> >> (For handy reference in this thread: http://goo.gl/zXoniR). If I could
> >> trouble you, could you also do a non-ccache parallel build? No rush,
> >> of course.
> >
> > Full parallel build is out now.
> >
> > On my machine you've cut the build time by 32 seconds. That's a 40%
> > reduction in build time.
>
> Hmm. My own single Makefile parallel build is (I think, I'll have to
> re-test) about 5x the speed of a standard build, so this is a little
> disappointing.
>
> FWIW, I am currently sitting at SFO on my way home, so I hope I'll be
> able to pay some more attention to this soon.

How do your system specs compare to Nathan's? For another quick, rough benchmark, I can say that a full-blast GitMake takes 11.5sec on my Mac Pro; the single-Makefile scheme takes about 10.5sec.

Mike

> > Good job.
> >
> >         Nathan
> >
> > --
> > http://wiki.openssl.org/index.php/Unit_Testing
> > ---
> > You received this message because you are subscribed to the Google Groups "openssl-testing" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to openssl-testi...@googlegroups.com.
> > To post to this group, send email to openssl...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/openssl-testing.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/openssl-testing/20140822053947.GA12412%40gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> http://wiki.openssl.org/index.php/Unit_Testing
> ---
> You received this message because you are subscribed to the Google Groups "openssl-testing" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openssl-testi...@googlegroups.com.
> To post to this group, send email to openssl...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openssl-testing.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openssl-testing/CAG5KPzzMYMBHeD7DgfMU93wR7yfoP%3Dz0M66zW83ZjdKzX%3DccLA%40mail.gmail.com.

[Nathan Typanski]

On Sat, Aug 23, 2014 at 6:11 PM, Ben Laurie <b...@links.org> wrote:
> Hmm. My own single Makefile parallel build is (I think, I'll have to
> re-test) about 5x the speed of a standard build, so this is a little
> disappointing.

Oh - I wasn't planning on posting this (since it's a personal blog) but
I did a more detailed analysis on my benchmarks, with statistical
significance tests over here:

<http://nathantypanski.com/blog/2014-08-22-openssl-makefiles.html>

It has an easier-to-work-with CSV dataset linked in the post, if you're
going to be running tests yourself. For me, the interesting bit is this:

> > t.test(real ~ branch, data=fullpar)
>
> Welch Two Sample t-test
>
> data: real by branch
> t = 31.1981, df = 13.113, p-value = 1.084e-13
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
> 30.60205 35.15128
> sample estimates:
> mean in group master mean in group mbland-makefiles-00
> 81.24000 48.36333

Which is basically just saying "yes, the full parallel builds are definitely
at least 30-35 seconds faster with Mike's Makefiles."

But I also confirmed the significance of my ccache build statistics
(namely, that the full sequential and full parallel builds with ccache
still show speed improvements of 3-5 seconds over master, respectively.

> FWIW, I am currently sitting at SFO on my way home, so I hope I'll be
> able to pay some more attention to this soon.

If your single-makefile builds beat even these times, I would find that
interesting to look at. Also important is whether they handle
dependencies correctly for the unit tests (and, honestly, everything),
though.

In the case of Mike's builds, he's solved the problem where going in and
modifying `ssl/d1_both.c` and then running `make TESTS=heartbeat_test
test` does not notice the changes in `d1_both.c`.

i.e., it's mostly just a side-benefit that parallel builds are way
faster now; the actual motivation for the changes was to improve
developers' lives by making OpenSSL easier to test.

Nathan

[Ben Laurie]

On 23 August 2014 15:51, Mike Bland <mbl...@acm.org> wrote:
> [Forgot to reply-all the first time.]
>
> On Aug 23, 2014 6:11 PM, "Ben Laurie" <b...@links.org> wrote:
>>
>> On 21 August 2014 22:39, Nathan Typanski <ntyp...@gmail.com> wrote:
>> > On 08/21, Mike Bland wrote:
>> >> Thanks for doing all this work to reproduce and extend my results.
>> >> (For handy reference in this thread: http://goo.gl/zXoniR). If I could
>> >> trouble you, could you also do a non-ccache parallel build? No rush,
>> >> of course.
>> >
>> > Full parallel build is out now.
>> >
>> > On my machine you've cut the build time by 32 seconds. That's a 40%
>> > reduction in build time.
>>
>> Hmm. My own single Makefile parallel build is (I think, I'll have to
>> re-test) about 5x the speed of a standard build, so this is a little
>> disappointing.
>>
>> FWIW, I am currently sitting at SFO on my way home, so I hope I'll be
>> able to pay some more attention to this soon.
>
> How do your system specs compare to Nathan's? For another quick, rough
> benchmark, I can say that a full-blast GitMake takes 11.5sec on my Mac Pro;
> the single-Makefile scheme takes about 10.5sec.

My machines are a lot slower, which might explain the relative
difference in speedup. I blame ZFS (I should try tuning it some).

Anyway, I'll compare Mike's build when I get home. Ish.

[Didier Cruette]

Hi

On a windows build I have this error since several days

sh ./tx509 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
x509-fff.p x509-f.p differ: char 28, line 1
make[1]: *** [test_x509] Error 1
make[1]: Leaving directory `/d/LogicielDeBaseQcr/Jenkins/jobs/qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows-bland/workspace/test'
make: *** [tests] Error 2

Didier