I am using Ubuntu 14.04.5 LTS (64b bit).
If I don't modify anything then my test application runs fine and it load OpenSSL 1.0.1f 6 Jan 2014 from the default
directory.
ldd libpq.so
linux-vdso.so.1 => (0x00007fff74af1000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fce422ac000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fce41ecf000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fce41cb1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fce418e8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fce416e4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fce42759000)
If I modify the LD_LIBRARY_PATH to force load LibreSSL 3.6.1 with:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/rothsoft/engines/postgreSQL/Linux/postgresql/libressl/
then LibreSSL 3.6.1 is correctly loaded:
ldd libpq.so
./libpq.so: libssl.so.1.0.0: no version information available (required by ./libpq.so)
./libpq.so: libcrypto.so.1.0.0: no version information available (required by ./libpq.so)
linux-vdso.so.1 => (0x00007fffc5753000)
libssl.so.1.0.0 (0x00007fb72ed6e000)
libcrypto.so.1.0.0 (0x00007fb72e919000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb72e6fb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb72e332000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb72f22a000)
I can see the it correctly loads LibreSSL with SSLeay_version(0)) but it crashes when it tried to execute any other TLS
function:
gdb ./postgresql_test
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./postgresql_test...(no debugging symbols found)...done.
(gdb) r
Starting program: /root/rothsoft/engines/postgreSQL/Linux/postgresql/libressl/postgresql_test
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error
warning: File "/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path'
setto "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /lib/x86_64-linux-gnu/libthread_db-1.0.so
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
name: PostgreSQL
version: 2.0.0
copy: (c) 2022 SQLabs
desc: PostgreSQL database engine for cubeSQL (LibreSSL 3.6.1)
Program received signal SIGSEGV, Segmentation fault.
pqsecure_raw_write (conn=0x3, ptr=0x629d60, len=314) at fe-secure.c:367
367 if (conn->write_failed)
---
Marco
> On 5 Dec 2022, at 02:14, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sun, Dec 04, 2022 at 09:02:07AM +0100, Marco Bambini wrote:
>> After several attempts (and runtime crashes), I am asking for help
>> with how to compile libpq with LibreSSL support (both dynamic and
>> static links would be OK to me).
>> I know how to compile libpq with OpenSSL support, but I need to
>> force it to link to LibreSSL.
>
> LibreSSL is rather close to OpenSSL in terms of API compatibility as
> far as I recall, OpenBSD using it. Note that we have two buildfarm
> members that I guess are doing so (adding Mikael in CC to confirm
> here): morepork and plover.
>
> The configure option --with-openssl would be the one to use, but you'd
> better be sure that CFLAGS is pointing at the path(s) of the headers
> of LibreSSL and that LDFLAGS points to the libraries of LibreSSL if
> you have an environment mixing both. Then at run-time, you could
> force LD_LIBRARY_PATH to load the right thing.
>
> There may be trickier things like building with OpenLDAP for example,
> as Postgres built with --with-ldap could link to a version of OpenLDAP
> linking to OpenSSL, but you'd want LibreSSL for a full consistency, so
> be careful.. The same could happen with Python, but without knowing
> what kind of environment you are using it will be hard to reach a
> clear conclusion without at least more details.
> --
> Michael