On OpenBSD, FreeBSD, Debian, and Ubuntu setting a library as
executable means you can run it directly, and since ./libressl.so
won't work it shouldn't be 755.
Ten minutes of research reveals that Red Hat sets the execute bit on
all shared libraries, and while its ldd script complains if it's not
Hi Jan,
On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote:
On Sunday 2014-07-13 13:07, Bob Beck wrote:
We have released an update, LibreSSL 2.0.1
As noted before, we welcome feedback from the broader community.
Something that I have noticed is that the shared libraries
On Monday 2014-07-14 20:16, Toni Mueller wrote:
Hi Jan,
On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote:
On Sunday 2014-07-13 13:07, Bob Beck wrote:
We have released an update, LibreSSL 2.0.1
As noted before, we welcome feedback from the broader community.
Something that I
What problem are you trying to solve here.
On Mon, Jul 14, 2014 at 12:28 PM, Jan Engelhardt jeng...@inai.de wrote:
On Monday 2014-07-14 20:16, Toni Mueller wrote:
Hi Jan,
On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote:
On Sunday 2014-07-13 13:07, Bob Beck wrote:
We have
On Monday 2014-07-14 20:34, Bob Beck wrote:
What problem are you trying to solve here.
Pristine libtool does not pass -m 644, and default (GNU) install
defaults to mode 755 when not specifying anything else.
I am trying to figure out why OpenBSD would be patching libtool
and adding
+case
2014-07-14 21:30 GMT+02:00 Jan Engelhardt jeng...@inai.de:
On Monday 2014-07-14 20:34, Bob Beck wrote:
What problem are you trying to solve here.
Pristine libtool does not pass -m 644, and default (GNU) install
defaults to mode 755 when not specifying anything else.
I am trying to figure
On Sunday 2014-07-13 13:07, Bob Beck wrote:
We have released an update, LibreSSL 2.0.1
As noted before, we welcome feedback from the broader community.
Something that I have noticed is that the shared libraries generated
by the portable libressl tarball are installed to their final
location (in
