There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
It turns out that libcrypto had an exectuable stack, because it linked
some objects without a .note.GNU-stack section. Compilers add this
section by default, but the objects produced from .S files did not
contain it. The .S files do include a directive to add the section, but
guarded behind an #ifdef HAVE_GNU_STACK. So define HAVE_GNU_STACK, to
ensure that all objects have a .note.GNU-stack section.
For some reasons, libcrypto would be built with the executable stack
flag set. I found out about this when Nginx failed to load the shared
library, because I was running it with MemoryDenyWriteExecute=true,
which does not permit executable stacks.
I am not sure why the stack ends up executable; the other shared
libraries which are part of LibreSSL do not have this flag set. You can
verify this with 'execstack -q'. Non-executable stacks should be the
default, and from checking some other files, that does appear to be the
case. The LibreSSL sources do not contain the string "execstack", so
I am not sure what causes the default to be overridden.
Adding '-z noexecstack' to the linker flags makes the linker unset the
flag. Now my Nginx can load the library, and so far I have not run into
other issues.
Without setting BUILD_SHARED_LIBS, the package would build file, but
when linking it into acme-client or nginx, I got the following error:
libressl-2.9.1/lib/libtls.a(tls.c.o): undefined reference to symbol 'pthread_once@@GLIBC_2.2.5'
binutils-2.31.1/bin/ld: glibc-2.27/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
After looking at the CMakeLists.txt in libressl/tls, I noticed the
BUILD_SHARED_LIBS option, and setting it resolves the linking error.
LibreSSL 2.9.1 no longer builds with the default autotools configuration.
When I searched for the error, I noticed that Buildroot ran into the
same issue, and they resolved the problem by building with CMake rather
than autotools. [1] I followed the same approach here.
[1]: e783d60473
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
This does not remove any prior versions: LibreSSL versions are
maintained for a year after their corresponding OpenBSD branch is tagged
for release:
- v2.6.x, part of OpenBSD 6.2-release, Nov 2017 (EOL: Nov 2018)
- v2.7.x, part of OpenBSD 6.3-release, Apr 2018 (EOL: Apr 2019)
- v2.8.x, expected OpenBSD 6.4-release, ETA Sep 2018 (EOL: Sep 2019)
This also does not change the default version: the stable branch remains
2.7.x, and 2.8.0 is the newest released development version. 2.8 can
become the default after OpenBSD-6.4
Closes#44760 (as it's redundant).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/libressl/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/2sj5bh1lwzls0vc31v2fhxaw648n0i9v-libressl-2.7.4-bin/bin/ocspcheck had a zero exit code or showed the expected version
- /nix/store/2sj5bh1lwzls0vc31v2fhxaw648n0i9v-libressl-2.7.4-bin/bin/openssl passed the binary check.
- 1 of 2 passed binary check by having a zero exit code.
- 1 of 2 passed binary check by having the new version present in output.
- found 2.7.4 with grep in /nix/store/2sj5bh1lwzls0vc31v2fhxaw648n0i9v-libressl-2.7.4-bin
- directory tree listing: https://gist.github.com/e28b9d47b987d9408427c7ec06e3b9fb
- du listing: https://gist.github.com/0d61c26c272780f10c5ce5359fb79bc7
I still feel weird about doing this because it seems a little hacky
but this was requested by @Mic92 and seems understandable to not want
to mix up libressl outputs with netcat stuff.
