Building OpenSSL from sources

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Building OpenSSL from sources

Dmitry Belyavsky-3
Hello,

I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy (oldstable).

After running ./config; make; make test; sudo make install 

I call  /usr/local/bin/openssl 

I get an error 

/usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

$ ldd /usr/local/bin/openssl 
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found

This behavior differs from the one for version 1.1.0b, where everything works fine. 

According to CHANGES in 1.1.0c

 *) Removed automatic addition of RPATH in shared libraries and executables,
     as this was a remainder from OpenSSL 1.0.x and isn't needed any more.
     [Richard Levitte]

Could you please clarify why this changes were introduced? 

Shouldn't the INSTALL file be changed to document this change 
because the proposed way (  ./config; make; make test; make install) does not work?

Thank you!

--
SY, Dmitry Belyavsky

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenSSL from sources

Wouter Verhelst-2
Hi Dmitry,

On 15-02-18 09:00, Dmitry Belyavsky wrote:

> Hello,
>
> I get problems building and installing OpenSSL 1.1.0g from source. I
> use Debian Wheezy (oldstable).
>
> After running ./config; make; make test; sudo make install 
>
> I call  /usr/local/bin/openssl 
>
> I get an error 
>
> /usr/local/bin/openssl: error while loading shared libraries:
> libssl.so.1.1: cannot open shared object file: No such file or directory
>
> $ ldd /usr/local/bin/openssl 
>         libssl.so.1.1 => not found
>         libcrypto.so.1.1 => not found
>
> This behavior differs from the one for version 1.1.0b, where
> everything works fine. 
>
> According to CHANGES in 1.1.0c
>
>  *) Removed automatic addition of RPATH in shared libraries and
> executables,
>      as this was a remainder from OpenSSL 1.0.x and isn't needed any more.
>      [Richard Levitte]
>
> Could you please clarify why this changes were introduced?

RPATH has certain semantics which are unexpected for some users (e.g.,
copying files around and updating ld.so.conf won't work). They have
their uses, but a build system using them *by default* is not
necessarily a good idea.

> Shouldn't the INSTALL file be changed to document this change 
> because the proposed way (  ./config; make; make test; make install)
> does not work?

It should, but you may have to check your dynamic linker configuration
to make sure that the library in which libssl is installed is found in
your library search path.

Check /etc/ld.so.conf (and directories included from that file, if any)
to make sure that it contains the directory where libssl.so ends up. If
it does not, add it, and then run 'ldconfig' without arguments to update
the cache.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenSSL from sources

Richard Levitte - VMS Whacker-2
In reply to this post by Dmitry Belyavsky-3
In message <CADqLbzKOvHz=[hidden email]> on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky <[hidden email]> said:

beldmit> Hello,
beldmit>
beldmit> I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy
beldmit> (oldstable).
beldmit>
beldmit> After running ./config; make; make test; sudo make install
beldmit>
beldmit> I call /usr/local/bin/openssl
beldmit>
beldmit> I get an error
beldmit>
beldmit> /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object
beldmit> file: No such file or directory
beldmit>
beldmit> $ ldd /usr/local/bin/openssl
beldmit> libssl.so.1.1 => not found
beldmit> libcrypto.so.1.1 => not found
beldmit>
beldmit> This behavior differs from the one for version 1.1.0b, where everything works fine.
beldmit>
beldmit> According to CHANGES in 1.1.0c
beldmit>
beldmit> *) Removed automatic addition of RPATH in shared libraries and executables,
beldmit> as this was a remainder from OpenSSL 1.0.x and isn't needed any more.
beldmit> [Richard Levitte]
beldmit>
beldmit> Could you please clarify why this changes were introduced?

The change was made for a very specific reason, it screwed up testing,
and here's how.

On GNU systems (for example Linux), '-Wl,-rpath,/path/to/installed/lib'
sets DT_RPATH.  If you read the ld.so manual, you will see that
DT_RPATH is used before anything else that affects what directories
are looked into, including LD_LIBRARY_PATH.

This meant that when running a new build of 'openssl' before
installing it, it would look for a previously installed version of the
libraries instead of those in the build directory.

A solution that we did use was to use LD_PRELOAD, which comes before
even DT_RPATH.  This worked well for quite a while.

Enter asan and ubsan.  I don't remember which one it was, but I think
it was one of those that was royally screwed up by our preloading the
shared libraries in the build directory.  It simply didn't work.

There is of course the solution to use '-Wl,--enable-new-dtags,-rpath,
/path/to/installed/lib', but that wouldn't work on older ELF systems

Another factor in all of this is that the reason we used -rpath to
begin with was that up until OpenSSL 1.0.2, we installed the libraries
in a non-standard directory (/usr/local/ssl/lib) by default.  This is
not longer so, the default location is /usr/local/lib, which should be
one of the standard ld.so directories.

In the end, we (or I, I don't remember) concluded that we didn't
actually need a compulsary use of -rpath and that this should be left
to the user.

beldmit> Shouldn't the INSTALL file be changed to document this change
beldmit> because the proposed way ( ./config; make; make test; make
beldmit> install) does not work?

Actually, this is documented, in NOTES.UNIX, which is mentioned in the
beginning of INSTALL:


 For additional platform specific requirements, solutions to specific
 issues and other details, please read one of these:

  * NOTES.UNIX (any supported Unix like system)
  * NOTES.VMS (OpenVMS)
  * NOTES.WIN (any supported Windows)
  * NOTES.DJGPP (DOS platform with DJGPP)

You see, INSTALL is supposed to be fairly platform agnostic...

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenSSL from sources

Dmitry Belyavsky-3
Dear Richard, 

On Thu, Feb 15, 2018 at 11:48 AM, Richard Levitte <[hidden email]> wrote:
In message <CADqLbzKOvHz=[hidden email]> on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky <[hidden email]> said:

beldmit> Hello,
beldmit>
beldmit> I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy
beldmit> (oldstable).
beldmit>
beldmit> After running ./config; make; make test; sudo make install
beldmit>
beldmit> I call /usr/local/bin/openssl
beldmit>
beldmit> I get an error
beldmit>
beldmit> /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object
beldmit> file: No such file or directory
beldmit>
beldmit> $ ldd /usr/local/bin/openssl
beldmit> libssl.so.1.1 => not found
beldmit> libcrypto.so.1.1 => not found
beldmit>
beldmit> This behavior differs from the one for version 1.1.0b, where everything works fine.
beldmit>
beldmit> According to CHANGES in 1.1.0c
beldmit>
beldmit> *) Removed automatic addition of RPATH in shared libraries and executables,
beldmit> as this was a remainder from OpenSSL 1.0.x and isn't needed any more.
beldmit> [Richard Levitte]
beldmit>
beldmit> Could you please clarify why this changes were introduced?

The change was made for a very specific reason, it screwed up testing,
and here's how.

On GNU systems (for example Linux), '-Wl,-rpath,/path/to/installed/lib'
sets DT_RPATH.  If you read the ld.so manual, you will see that
DT_RPATH is used before anything else that affects what directories
are looked into, including LD_LIBRARY_PATH.

This meant that when running a new build of 'openssl' before
installing it, it would look for a previously installed version of the
libraries instead of those in the build directory.

A solution that we did use was to use LD_PRELOAD, which comes before
even DT_RPATH.  This worked well for quite a while.

Enter asan and ubsan.  I don't remember which one it was, but I think
it was one of those that was royally screwed up by our preloading the
shared libraries in the build directory.  It simply didn't work.

There is of course the solution to use '-Wl,--enable-new-dtags,-rpath,
/path/to/installed/lib', but that wouldn't work on older ELF systems

Another factor in all of this is that the reason we used -rpath to
begin with was that up until OpenSSL 1.0.2, we installed the libraries
in a non-standard directory (/usr/local/ssl/lib) by default.  This is
not longer so, the default location is /usr/local/lib, which should be
one of the standard ld.so directories.

In the end, we (or I, I don't remember) concluded that we didn't
actually need a compulsary use of -rpath and that this should be left
to the user.

beldmit> Shouldn't the INSTALL file be changed to document this change
beldmit> because the proposed way ( ./config; make; make test; make
beldmit> install) does not work?

Actually, this is documented, in NOTES.UNIX, which is mentioned in the
beginning of INSTALL:


 For additional platform specific requirements, solutions to specific
 issues and other details, please read one of these:

  * NOTES.UNIX (any supported Unix like system)
  * NOTES.VMS (OpenVMS)
  * NOTES.WIN (any supported Windows)
  * NOTES.DJGPP (DOS platform with DJGPP)

You see, INSTALL is supposed to be fairly platform agnostic...


Thank you very much for your comprehensive explanation!

But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario?


--
SY, Dmitry Belyavsky

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenSSL from sources

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Fri, 16 Feb 2018 10:59:04 +0300, Dmitry Belyavsky <[hidden email]> said:

beldmit> But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario?

Maybe, depending on why.  If it's to create the appropriate symlinks,
you might notice that we do that ourselves using 'ln -s' (if the
symlinks are wrong, please raise an issue on github).  If it's for the
cache, we could of course add some kind of post-shared config
attribute to reflect that need (a little like we have one for ranlib).

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenSSL from sources

Dmitry Belyavsky-3
Dear Richard,

On Fri, Feb 16, 2018 at 12:26 PM, Richard Levitte <[hidden email]> wrote:
In message <[hidden email]> on Fri, 16 Feb 2018 10:59:04 +0300, Dmitry Belyavsky <[hidden email]> said:

beldmit> But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario?

Maybe, depending on why.  If it's to create the appropriate symlinks,
you might notice that we do that ourselves using 'ln -s' (if the
symlinks are wrong, please raise an issue on github).  If it's for the
cache, we could of course add some kind of post-shared config
attribute to reflect that need (a little like we have one for ranlib).


I mean to update the cache.


--
SY, Dmitry Belyavsky

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users