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. I think this thread excerpt explains it: https://lists.apache.org/thread/3rvvgxnws9867krk75rw6bvhmds1t2co [...] > ============================== > LINK STATICALLY OR SET RPATH? > ============================== > > There are 2 ways to fix this: > 1. Provide only static OpenSSL libraries at build and run time, to force > Curl to link to OpenSSL statically. > 2. Provide OpenSSL dynamically, but set RPATH to $ORIGIN in all binaries > that use it (including Curl), so they can find the local OpenSSL copy that > ships with OpenOffice. > > Arrigo: why did you ever make OpenSSL deliver dynamic libraries? Were you > planning to implement option 2? Not at all. I just wanted to fix the problem of the (required) OpenSSL libraries missing from the AOO distribution. I now agree that 1. is the best solution, and that my commit including the .so files was sort of a wrong solution to the problem. 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. > Why was OpenOffice ever using option 1, always linking statically to > OpenSSL on *nix? We can't tell from our Git log, because it was done before > we got the code, and we don't have history going that far back. But if I > had to guess, I would say that the OpenSSL API is unstable, and yet OpenSSL > is widely used, and when different versions of OpenSSL (eg. one internal, > one system) were loaded into memory by different dependencies, it led to > conflicts. That seems reasonable to me. > 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. I hope this helps making my intentions at the time more clear now. Thank you for the efforts you are putting into this issue! Best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
