[Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
Oh, hello again,

now i finally have updated (without "make tests?") and it seems
i now have to fill in $LD_LIBRARY_PATH to get running:

  $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl
  ...
  libssl.so.1.1 => not found
  libcrypto.so.1.1 => not found

This is new behaviour, until now the installation was always
self-contained when configured via

  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared

I think this should at least be noted in CHANGES or so.
Ciao,

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Salz, Rich
> This is new behaviour, until now the installation was always self-contained
> when configured via
>
>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared

Did you install the libraries in a standard place?

> I think this should at least be noted in CHANGES or so.

I don't think so.  I think the libs weren't installed.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
"Salz, Rich" <[hidden email]> wrote:
 |> This is new behaviour, until now the installation was always self-contain\
 |> ed
 |> when configured via
 |>
 |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |
 |Did you install the libraries in a standard place?
 |
 |> I think this should at least be noted in CHANGES or so.
 |
 |I don't think so.  I think the libs weren't installed.

Yes, also in my opinion the old behaviour was much, much better.

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Viktor Dukhovni
In reply to this post by Steffen Nurpmeso-2

> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso <[hidden email]> wrote:
>
>  $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl
>  ...
>  libssl.so.1.1 => not found
>  libcrypto.so.1.1 => not found
>
> This is new behaviour, until now the installation was always
> self-contained when configured via
>
>  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared

I sure hope that "$()" was in fact "${}", the former only
works in Makefiles, and means something quite different
in POSIX shells.

You need an "RPATH" setting in the linker flags for the shared
libraries to be found in in $PREFIX/lib.  Perhaps:

    ./config --prefix="${MYPREFIX}" -R "${MYPREFIX}/lib" ...

Or "-rpath ..." or "-Wl,-R,..." ...

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Richard Levitte - VMS Whacker-2
In reply to this post by Steffen Nurpmeso-2
In message <20170301165032.8jhWg%[hidden email]> on Wed, 01 Mar 2017 17:50:32 +0100, Steffen Nurpmeso <[hidden email]> said:

steffen> "Salz, Rich" <[hidden email]> wrote:
steffen>  |> This is new behaviour, until now the installation was always self-contain\
steffen>  |> ed
steffen>  |> when configured via
steffen>  |>
steffen>  |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
steffen>  |
steffen>  |Did you install the libraries in a standard place?
steffen>  |
steffen>  |> I think this should at least be noted in CHANGES or so.
steffen>  |
steffen>  |I don't think so.  I think the libs weren't installed.
steffen>
steffen> Yes, also in my opinion the old behaviour was much, much better.

I very much disagree.  We have had bug reports as well as cases of our
own because a new compilation that you want to test picked up
previously installed versions of the libraries (usually an older
version).  The reason for doing so previously was because we installed
the libraries in non-standard locations by default.

Since OpenSSL 1.1.0 and on is installing in standard locations by
default, we don't have to use these mechanisms for a default build.
With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they
are different) or whatever isn't really our decision to make, but the
decision of the packager or the individual user, so we've handed the
decision to you.

For the GNU toolchain, I'd recommend configuring with something like
this (from memory, I might be fuzzy in the details):

    -Wl,--enable-new-dtags -rpath '$(LIBRPATH)'

LIBRPATH is a convenience Makefile variable that gets correctly set to
the configured shared library installation directory, meant for
exactly this sort of situation.

Cheers,
Richard

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

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
In reply to this post by Viktor Dukhovni
Good evening.

Viktor Dukhovni <[hidden email]> wrote:
 |> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso <[hidden email]> wrote:
 |>
 |>  $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl
 |>  ...
 |>  libssl.so.1.1 => not found
 |>  libcrypto.so.1.1 => not found
 |>
 |> This is new behaviour, until now the installation was always
 |> self-contained when configured via
 |>
 |>  ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |
 |I sure hope that "$()" was in fact "${}", the former only
 |works in Makefiles, and means something quite different
 |in POSIX shells.

No it is a snippet from a makefile, of course.

 |You need an "RPATH" setting in the linker flags for the shared
 |libraries to be found in in $PREFIX/lib.  Perhaps:

If my tortured ears finally hear, then.  You are saying this never
was standard behaviour?  Oh!?!  Well, then i am sorry, it could
indeed be that i never ran the binaries in there, but only use
this one for v1.1.0 link testing, and then, there, the linker path
is adjusted automatically (by my configuration script).

It may be a crappy comment, but if i ldd(1)
~/usr/opt/.ressl/bin/openssl then this just works, and the make
rule is almost identical:

  libressl:
          cd libressl.tar_bomb_git &&\
          if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
          ./configure --prefix=$(MYPREFIX) &&\
          make &&\
          make check &&\
          $(SUDO) make install;\
          { git clean -fxd; git reset --hard HEAD;\
          git checkout arena-manager-null; } >/dev/null

But thanks, i did not know that i can pass additional flags to
./config!  Thanks to Matt Caswell i think, if i recall correctly,
i now know about "make install_sw && make install_ssldirs", and
maybe in a not too distant future i get it right!

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
In reply to this post by Richard Levitte - VMS Whacker-2
Hello,

Richard Levitte <[hidden email]> wrote:
 |In message <20170301165032.8jhWg%[hidden email]> on Wed, 01 Mar \
 |2017 17:50:32 +0100, Steffen Nurpmeso <[hidden email]> said:
 |
 |steffen> "Salz, Rich" <[hidden email]> wrote:
 |steffen>  |> This is new behaviour, until now the installation was \
 |always self-contain\
 |steffen>  |> ed
 |steffen>  |> when configured via
 |steffen>  |>
 |steffen>  |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
 |steffen>  |
 |steffen>  |Did you install the libraries in a standard place?
 |steffen>  |
 |steffen>  |> I think this should at least be noted in CHANGES or so.
 |steffen>  |
 |steffen>  |I don't think so.  I think the libs weren't installed.
 |steffen>
 |steffen> Yes, also in my opinion the old behaviour was much, much better.
 |
 |I very much disagree.  We have had bug reports as well as cases of our
 |own because a new compilation that you want to test picked up
 |previously installed versions of the libraries (usually an older
 |version).  The reason for doing so previously was because we installed
 |the libraries in non-standard locations by default.

That unpuzzles me a little bit -- this behaviour did exist.  Good.

 |Since OpenSSL 1.1.0 and on is installing in standard locations by
 |default, we don't have to use these mechanisms for a default build.
 |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they
 |are different) or whatever isn't really our decision to make, but the
 |decision of the packager or the individual user, so we've handed the
 |decision to you.
 |
 |For the GNU toolchain, I'd recommend configuring with something like
 |this (from memory, I might be fuzzy in the details):
 |
 |    -Wl,--enable-new-dtags -rpath '$(LIBRPATH)'
 |
 |LIBRPATH is a convenience Makefile variable that gets correctly set to
 |the configured shared library installation directory, meant for
 |exactly this sort of situation.

The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes,
when i reported the dynamic link test failures a while back i have
seen that and also added support for this new linker flag to my
software.  It is i think off-topic that now new environment
variables come up that makes me wonder why the LD_PRELOAD ..
DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared
deprecated.

LIBRPATH i did not know about yet, thanks for the pointer, i will
read about it.
Yes, i mean, i just didn't know this, it is not mentioned anywhere
(i think that would well be worth in entry in INSTALL), and
i really would have sworn that it worked in the past.

Thank you, and
Ciao!

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Richard Levitte - VMS Whacker-2
In message <20170301221703.tFwPU%[hidden email]> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmeso <[hidden email]> said:

steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere
steffen> (i think that would well be worth in entry in INSTALL), and
steffen> i really would have sworn that it worked in the past.

I was actually surprised to find this undocumented.  I could have
sworn I'd done so, but apparently, I only did in a commit message:

    commit fad599f7f147ee71e5581211fb654c2c8c491cd8
    Author: Richard Levitte <[hidden email]>
    Date:   Wed Oct 12 17:05:35 2016 +0200
   
        Remove automatic RPATH - add user rpath support
       
        Make Configure recognise -rpath and -R to support user added rpaths
        for OSF1 and Solaris.  For convenience, add a variable LIBRPATH in the
        Unix Makefile, which the users can use as follows:
       
            ./config [options] -Wl,-rpath,\$(LIBRPATH)
       
        Reviewed-by: Rich Salz <[hidden email]>

I'll go add a note now...

Sorry

Cheers,
Richard

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

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
Hello.

Richard Levitte <[hidden email]> wrote:
 |In message <20170301221703.tFwPU%[hidden email]> on Wed, 01 Mar \
 |2017 23:17:03 +0100, Steffen Nurpmeso <[hidden email]> said:
 |
 |steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere
 |steffen> (i think that would well be worth in entry in INSTALL), and
 |steffen> i really would have sworn that it worked in the past.
 |
 |I was actually surprised to find this undocumented.  I could have
 |sworn I'd done so, but apparently, I only did in a commit message:
 |
 |    commit fad599f7f147ee71e5581211fb654c2c8c491cd8
 |    Author: Richard Levitte <[hidden email]>
 |    Date:   Wed Oct 12 17:05:35 2016 +0200
 |    
 |        Remove automatic RPATH - add user rpath support
 |        
 |        Make Configure recognise -rpath and -R to support user added rpaths
 |        for OSF1 and Solaris.  For convenience, add a variable LIBRPATH \
 |        in the
 |        Unix Makefile, which the users can use as follows:
 |        
 |            ./config [options] -Wl,-rpath,\$(LIBRPATH)
 |        
 |        Reviewed-by: Rich Salz <[hidden email]>
 |
 |I'll go add a note now...

Thank you very much.
Have a good time.

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Richard Levitte - VMS Whacker-2
In reply to this post by Steffen Nurpmeso-2
In message <20170301221703.tFwPU%[hidden email]> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmeso <[hidden email]> said:

steffen> Hello,
steffen>
steffen> Richard Levitte <[hidden email]> wrote:
steffen>  |In message <20170301165032.8jhWg%[hidden email]> on Wed, 01 Mar \
steffen>  |2017 17:50:32 +0100, Steffen Nurpmeso <[hidden email]> said:
steffen>  |
steffen>  |steffen> "Salz, Rich" <[hidden email]> wrote:
steffen>  |steffen>  |> This is new behaviour, until now the installation was \
steffen>  |always self-contain\
steffen>  |steffen>  |> ed
steffen>  |steffen>  |> when configured via
steffen>  |steffen>  |>
steffen>  |steffen>  |>   ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared
steffen>  |steffen>  |
steffen>  |steffen>  |Did you install the libraries in a standard place?
steffen>  |steffen>  |
steffen>  |steffen>  |> I think this should at least be noted in CHANGES or so.
steffen>  |steffen>  |
steffen>  |steffen>  |I don't think so.  I think the libs weren't installed.
steffen>  |steffen>
steffen>  |steffen> Yes, also in my opinion the old behaviour was much, much better.
steffen>  |
steffen>  |I very much disagree.  We have had bug reports as well as cases of our
steffen>  |own because a new compilation that you want to test picked up
steffen>  |previously installed versions of the libraries (usually an older
steffen>  |version).  The reason for doing so previously was because we installed
steffen>  |the libraries in non-standard locations by default.
steffen>
steffen> That unpuzzles me a little bit -- this behaviour did exist.  Good.
steffen>
steffen>  |Since OpenSSL 1.1.0 and on is installing in standard locations by
steffen>  |default, we don't have to use these mechanisms for a default build.
steffen>  |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they
steffen>  |are different) or whatever isn't really our decision to make, but the
steffen>  |decision of the packager or the individual user, so we've handed the
steffen>  |decision to you.
steffen>  |
steffen>  |For the GNU toolchain, I'd recommend configuring with something like
steffen>  |this (from memory, I might be fuzzy in the details):
steffen>  |
steffen>  |    -Wl,--enable-new-dtags -rpath '$(LIBRPATH)'
steffen>  |
steffen>  |LIBRPATH is a convenience Makefile variable that gets correctly set to
steffen>  |the configured shared library installation directory, meant for
steffen>  |exactly this sort of situation.
steffen>
steffen> The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes,
steffen> when i reported the dynamic link test failures a while back i have
steffen> seen that and also added support for this new linker flag to my
steffen> software.  It is i think off-topic that now new environment
steffen> variables come up that makes me wonder why the LD_PRELOAD ..
steffen> DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared
steffen> deprecated.
steffen>
steffen> LIBRPATH i did not know about yet, thanks for the pointer, i will
steffen> read about it.
steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere
steffen> (i think that would well be worth in entry in INSTALL), and
steffen> i really would have sworn that it worked in the past.
steffen>
steffen> Thank you, and
steffen> Ciao!

I've added a change with documentation:

https://github.com/openssl/openssl/pull/2818

Please go in and comment, or if you don't have a github account, feel
free to comment here.

Cheers,
Richard

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

Re: [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Steffen Nurpmeso-2
Hello.

Richard Levitte <[hidden email]> wrote:
 |I've added a change with documentation:
 |
 |https://github.com/openssl/openssl/pull/2818
 |
 |Please go in and comment, or if you don't have a github account, feel
 |free to comment here.

Thank you, i have added it to my makefile 1:1.
Ciao!

--steffen
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Loading...