[openssl-users] missing symbolic links under include directory

[Thomas Francis, Jr.]

> On Apr 21, 2016, at 3:06 AM, Tim Culhane <tim.j.culhane at gmail.com> wrote:
> 
> Hi all,
> 
> My company makes calls to functions in the openssl source and thus includes
> header files defined in the openssl library.
> 
> Typically these header files were gathered together in a simgle place, under
> include/openssl by way of symbolic links to the real header file locations.
> 
> At present I'm updating the version of openssl our products used from 1.0.1g
> to 1.0.2g, the latest stable release.
> 
> I noticed that when I unpacked the source code for openssl 1.0.2g that there
> were no symbolic links under the include/openssl directory.
> 
> These were present in versions of openssl as late as 1.0.1q.
> From looking through the mailing list archive, I believe this was a
> deliberate change in how openssl is packaged. Is this correct?
> 
> It appears that the configure or config script now needs to be run followed
> by make depend in order to regenerate the symbolic links.

You must run the configure script (and possibly make depend) to get the links created properly.  My understanding is the deliberate change was more in the way of correcting archives that were made incorrectly; you’ve always (at least as long as I’ve been using OpenSSL, which has been almost 20 years) had to do this.

It’s worth noting that configuring openssl will remove all of those links before creating them again, too, so as far as the symlinks go, having them around isn’t too bad, it’s just extra work.

> My issue is that our products check out the openssl source from a local git
> repository and the products build on both linux and sparc.
> 
> Therefore, if I commit the latest openssl source code to our git repository
> it must already contain the symbolic links required.

Why?  You should not keep installed headers in source control — you should use a binary repository (and keep the binaries and headers together) instead.  OR, see below...

> If I run config or configure followed by make depend before committing the
> source code to git, will I be generating any operating specific files or
> code?

Yes.  What’s worse is that if you commit all the files, when you try to configure OpenSSL on the second platform, it’ll tell you that it’s already been configured for the first platform and stop.

> In other words, if I do config on sparc followed by make depend and then
> commit the source to git, would there be any issues when I later checked out
> the
> files from git and built them on linux?

Again, yes, there will be problems.  If you want to build OpenSSL out of your source control on a regular basis, you should store the source files exactly as they exist in the tarball.  Remove those headers from your source control — you don’t need them in order to build; they’re just wasting space in your source control. :)

This means that each time you pull the code from source control, you configure and build the code as normal (which I assume you’re already doing — if not, OpenSSL probably isn’t working as it’s supposed to be working).

If you don’t want to build OpenSSL all the time (and unless you maintain your own patches, I strongly recommend against building it all the time), then don’t keep it under source control at all.  Keep it in some kind of binary repository which you update only when you need to upgrade OpenSSL (or add a patch, a new platform, etc).  Then use that for deploying OpenSSL to your build systems as needed (presumably only once per build system).  If you use some kind of system imaging to spin up new VMs for building, then make sure the OpenSSL installation is part of that system, so it gets installed with the new VM, not as part of your build process.  That has the additional benefit of reducing your build times. :)  If you need to have multiple versions of OpenSSL installed, simply configure each version to be installed to a different location (and install them to different locations), and adjust your other builds to look for the version they want in the version-specific location.  That has the additional benefit of making it clear to everyone what version of OpenSSL is used by what build.

TOM

<snip>