Hello Damjan, All,

On Sun, Apr 07, 2024 at 05:22:43PM +0000, Damjan Jovanovic wrote:

> On Sun, Apr 7, 2024 at 2:26 PM Arrigo Marchiori <ard...@apache.org> wrote:
> 
> > Hello Damjan, All,
> >
> > On Sun, Apr 07, 2024 at 01:53:08PM +0000, Damjan Jovanovic wrote:
> >
> > > Hi
> > >
> > > With Pedro Lino's help, I've discovered a serious regression, where Curl
> > > (and libraries that use Curl) can fail to load, because they've been
> > > dynamically linked to OpenSSL but cannot find the copy of OpenSSL shipped
> > > with OpenOffice.
> >
> > [big snip]
> >
> > [...]
> >
> > > When main/oox linked to internal OpenSSL, it did dynamically on Windows,
> > > and on *nix, dynamically to system OpenSSL, and statically to internal
> > > OpenSSL.
> >
> > I might have missed the end of this sentence: "statically to internal
> > OpenSSL".
> >
> > >
> > -----------------------------------------------------------------------------------------------
> > > 2022-05-06, commit 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3
> > >
> > -----------------------------------------------------------------------------------------------
> > > "Fix including OpenSSL dynamic libraries on Unix (#147)" by Arrigo.
> > >
> > > OpenSSL, on *nix, now starts delivering static and dynamic libraries, and
> > > packaging dynamic libraries at the end of the build.
> > > Curl continues using OpenSSL, but now since both static and dynamic
> > OpenSSL
> > > libraries are available, it favours the dynamic.
> > > main/oox still links to OpenSSL statically outside Windows.
> > > main/ucb still links to OpenSSL statically outside Windows.
> >
> > [...]
> >
> > > ============================
> > > CURL LOADS WRONG OPENSSL
> > > ============================
> > >
> > > Now the combination of these last 2 commits broke Curl (and possibly
> > python
> > > and redland as well) as follows:
> > > - Internal modules have their RPATH set to $ORIGIN (among others), and
> > thus
> > > always search for dependencies in the same directory as themselves at
> > > runtime.
> > > - Third-party modules usually do not set their RPATH. In libcurl.so, it's
> > > unset.
> > > - When only static libraries are present at link-time, the binary being
> > > linked, is linked to them statically. So before
> > > 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3, Curl was linking statically to
> > > OpenSSL.
> >
> > Apparently not. My purpose, with that commit, was to include the
> > OpenSSL libraries _linked by the AOO executable_, that were: dynamic.
> >
> > In other words, the SSL libraries were not linked statically when
> > building on my system. They were linked dynamically instead.
> >
> >
> What happens currently, with OpenSSL 3, if you revert most of
> 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3 (I think the makefile.mk change is
> still correct)? Does Curl still link to OpenSSL dynamically, or does it
> start linking statically? For me, on FreeBSD, it links statically.

Apparently, this is also happening on Linux.
After reverting 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3:

$ ldd solver/450/unxlngx6.pro/lib/libcurl.so
        linux-vdso.so.1 (0x00007ffe59dab000)
        libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007f1236400000)
        libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007f12362cf000)
        libbrotlidec.so.1 => /usr/lib64/libbrotlidec.so.1 (0x00007f1236000000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f12366f0000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f12366eb000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f12366c5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f1235e09000)
        libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00007f1235a00000)
        libbrotlicommon.so.1 => /usr/lib64/libbrotlicommon.so.1 
(0x00007f1235600000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1236c2e000)

OpenSSL libraries are not listed! They must be linked statically!

> > I think this thread excerpt explains it:
> > https://lists.apache.org/thread/3rvvgxnws9867krk75rw6bvhmds1t2co
> >
> >
> Is that horrible bug fixed now, or does Curl/OpenSSL still crash AOO in
> certain setups?

Now when I check for update I see a dialog box with the following
error message:

Status
  Checking for an update failed.
Description
  Error reading data from the Internet.
  Server error message: Problem with the SSL CA cert (path? access rights?).

I think that on trunk we had solved the crash, but automatic updates
were just failing silently.

I need to build ``untouched'' trunk and try again the above.

[...]
> > Honestly, I don't know in detail what RPATH is and how to change it,
> > and I would like to adopt the simplest approach to the problem.
> >
> 
> It is a ":"-separated list of paths where the binary's dependencies are
> searched for, before trying the system paths.
[...]

I thought the "soffice" shell script set the LD_LIBRARY_PATH
environment variable just for this purpose... but now I see it's just
used for Java.

[...]
> > > Maybe it's safe to link to OpenSSL dynamically now?
> >
> > I think that our ``official'' Linux build machines are quite outdated,
> > and for this reason it makes sense not to rely on their system
> > libraries.
> >
> >
> No, I meant link dynamically to an internal copy of OpenSSL we would ship,
> not to the distribution's OpenSSL.
> 
> What do you think of that?

I personally like dynamic linking best, because it makes the overall
AOO distribution (very slightly) smaller, avoiding duplicated
static library inclusions.

But we have to fix the RPATH issue as per your detailed explanation
(thanks!).

Best regards,
-- 
Arrigo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to