Build PETSc with ssl only when a dependency

[johannesring]

When building python with HashDist it will be built with openssl and when building petsc it will by default be built with ssl from the system. This leads to problems like the following when building dolfin:

CMake Warning at bench/fem/speedup/cpp/CMakeLists.txt:44 (add_executable):
  Cannot generate a safe runtime search path for target bench_solve-poisson
  because files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libssl.so.1.0.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /home/martinal/.hashdist/bld/profile/5c5xotjofrcc/lib
    runtime library [libcrypto.so.1.0.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /home/martinal/.hashdist/bld/profile/5c5xotjofrcc/lib

  Some of these libraries may not be found correctly.

The problem is that python and petsc is linked with different ssl libraries.

This PR makes sure that ssl is only turned on for petsc when openssl is added as a dependency. Otherwise it is turned off.

[certik]

That looks good. Or PETSc should be modified to link against the same ssl library as Python.

[johannesring]

How can we do that? Patching PETSc?

[certik]

Why does petsc need ssl in the first place? I know you can choose the ssl library for Python.

[ahmadia]

@certik - They have some crappy web interface voodoo in a very small optional module. @jedbrown - shouldn't this be off in a default PETSc install?

I agree with @johannesring - just disable it unless the user has indicated that SSL is a dependency.

[jedbrown]

@BarrySmith does the SSL stuff. What is wrong with autodetecting SSL? We autodetect Valgrind, for example, even though it's not required.

[ahmadia]

It's an implicit dependency for an optional and probably almost never-used module in PETSc. You don't auto-detect SuperLU, why should you auto-detect SSL?

[jedbrown]

Numerical packages usually need to be compatible in terms of int sizes, scalar precision, Fortran and MPI ABI, etc. Normally there is no way to test this, so it's dangerous and often wrong to autodetect. SSL normally doesn't have that problem, but does in case of cross-compilation. Anyway, you have a point and I would support turning it off by default, though @BarrySmith can make the final call.

[BarrySmith]

Hmm, is there no way to comment on another comment?

The default SSL is not actually used by the crappy web interface voodoo; it is used by something even more obscure, the ability to access Google Docs and Globus files from the application.

One reason for making it auto is that it helps very quickly detect problems with the code since the ssl.py tests and the source code in PETSc related to it are always run. By making it off by default it gets pretty much no testing nor chance for finding the problems.

And actually it has worked out pretty well. We've only had two issues reported related to the SSL stuff (one by Mark Adams and one here) which is much more stable than almost any of the "optional" packages we support.

With regard to cross compilation, as with all our tests the tests are suppose to handle the cross compilation business properly, that is they do not just test the "thing" on the host and assume that that it works on the cross system, the test is suppose to be relevent for the true system it will be run on. Of course this doesn't help when some vendors put dummy stubs into their libraries so ./configure runs fine but then the "dummy stubs" fail at run time.

Given that you guys have a solution to the problem and we've no other legitiment complaints I don't see any reason to not make it default.