Re: [reSIProcate] SSL Build Rules

[Max Bowsher <maxb@xxxxxxx>]

Adam Roach wrote:
> Max:
> 
> Be careful with the handling of SSL_LOCATION (and similar variables) --
> if we end up with system paths (like /usr/include or /usr/lib) in -I or
> -L switches, then the cross-compilation setup breaks in very bad ways
> that most people cannot easily troubleshoot.

Absolutely - I'm familiar with the pains that getting system paths in -I
and -L even for non-cross builds can cause.

However, for the SSL_LOCATION variable, this issue isn't a pressing
concern, since it's defined to be the location of an OpenSSL *source*
tree rather than an install location - or, the variable can be blank to
indicate that reSIProcate should use a system installation of OpenSSL.

If the user tries to point to an installation of OpenSSL using it, lots
of things are going to break in an obvious fashion.

> As an aside, I note that the handling of the SSL build rules in the main
> Makefile is pretty badly messed up anyway, from a portability
> perspective (e.g., hardcoding for 32-bit linux configuration). My
> inclination would be to remove them -- we don't currently build any
> other external dependencies; I'm not sure why OpenSSL should be
> different.

Scott's reply already addresses the reason, so I won't repeat that here.

As far as precedent is concerned, this use of openssl can be compared to
resiprocate's use of ares - but presumably it's out of tree because the
openssl source tree is rather large, and it's only required for reCon.

Max.

Attachment: signature.asc
Description: OpenPGP digital signature