Switch linux OpenSSL build to use custom openssl version

Switch linux OpenSSL build to use custom openssl version
This allows us to test experimental library features, and to track a known openssl version.
Also bumps OpenSSL 65717:68738, to fix up the default CA root path in the reference library.

BUG=None
TEST=Still builds & runs!

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=68749

[agl, 2010-12-08 18:16:38]

LGTM, although I thought that you *wanted* to link against the system OpenSSL to
save space?

[joth, 2010-12-08 20:16:47]

Size isn't an such an issue as we can switch between system of custom depending
on needs.

One side effect of this is the third_party openssl doesn't automatically pickup
the system root CA dir, so you have to run chromium with
SSL_CERT_DIR=/etc/ssl/certs/ (for example).
I'll hold off on committing this while I see if there's a way to make this
tidier (without hard-coding the path into the code).

[joth, 2010-12-09 12:35:18]

On 2010/12/08 20:16:47, joth wrote:
> One side effect of this is the third_party openssl doesn't automatically
pickup
> the system root CA dir, so you have to run chromium with
> SSL_CERT_DIR=/etc/ssl/certs/ (for example).
> I'll hold off on committing this while I see if there's a way to make this
> tidier (without hard-coding the path into the code).

a possible solution for this: reconfigure the third_party/openssl to follow the
ubuntu conventions:
http://codereview.chromium.org/5710001/

Let me know your thoughts (over on that review issue)

[joth, 2010-12-09 16:38:23]

On 2010/12/09 12:35:18, joth wrote:
> 
> Let me know your thoughts (over on that review issue)

Thanks. I've submitted that one, and included the corresponding DEPS roll in
here.

Still LGTY?

Cheers

[joth, 2010-12-09 17:15:02]

On 2010/12/09 16:38:23, joth wrote:
> 
> Still LGTY?
> 

Hold on, found another snag. The <openssl/ssl.h> includes are still getting the
system version (/usr/include) as the direct_dependent_settings does not
propagate out of the third_party/openssl to the net modules.

I guess the alternative is to leave linux/system.gyp alone, and change all the
users (net.gyp, base.gyp etc) to depend directly on the third_party/openssl.
Unless there's a standard way to declare an alias for a dependency in a GYP
file?

[agl, 2010-12-09 18:09:33]

On Thu, Dec 9, 2010 at 12:15 PM,  <joth@chromium.org> wrote:
> I guess the alternative is to leave linux/system.gyp alone, and change all
> the
> users (net.gyp, base.gyp etc) to depend directly on the third_party/openssl.
> Unless there's a standard way to declare an alias for a dependency in a GYP
> file?

#if defined(USE_SYSTEM_OPENSSL)
#include ...
#else
#include
#endif

?

AGL

[joth, 2010-12-09 18:15:19]

On 2010/12/09 18:09:33, agl wrote:
> 
> #if defined(USE_SYSTEM_OPENSSL)
> #include ...
> #else
> #include
> #endif
> 
> ?
> 
> AGL

I wondered about that, but realized #include <openssl/ssl.h> was working just
fine for you in flip server (i.e. getting 3rd party version).

I uploaded a new patch then gets rid of linux/system.gyp:openssl and have the
dependents depend on third_party/openssl directly, which solves it. (As shown by
the compile break in Kristian's code it now picks up, also fixed in that patch
:)

[agl, 2010-12-09 18:18:30]

On Thu, Dec 9, 2010 at 1:15 PM,  <joth@chromium.org> wrote:
> I uploaded a new patch then gets rid of linux/system.gyp:openssl and have
> the
> dependents depend on third_party/openssl directly, which solves it. (As
> shown by
> the compile break in Kristian's code it now picks up, also fixed in that
> patch
> :)
>
> http://codereview.chromium.org/5625012/

LGTM for any patch which fixes it.


AGL