Richard Levitte

> Maybe that could still be done via an option What sort of option are you thinking? Configuration would be strange, as this option would be just for testing runtime...

> Separately though, I think some of these casts may have documentary value - so I'm not entirely convinced that removing them is necessary. In all cases but one, the...

> I prefer having the casts in place as a matter of style. My preference is the opposite, at least when it's so clearly redundant.

This has a flaw. An application that's linked against libcrypto.a will not include *everything*, it will only include the object files from it that contains unresolved symbols. If the engine...

> > This has a flaw. An application that's linked against libcrypto.a will not include _everything_, it will only include the object files from it that contains unresolved symbols. If...

> > To absolutely guarantee that all of libcrypto.a gets pulled in when linking a program, you must do this: > > ``` > > $ gcc -pthread -o test-malloc...

> > ... which would mean that everyone (on a GNUish platform) that wants to use an engine in their program _must_ do it this way, as a result of...

This is curious... aren't those symbols part of libc, which I hope those shared objects are linked against?

How... annoying!

It's possible that it would be better if `util/wrap.pl` became a public tool. Not necessarily exactly as it works now, but something with a similar intent.