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. > 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? > [...] > > > ============================== > > 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. > It is a ":"-separated list of paths where the binary's dependencies are searched for, before trying the system paths. If it contains $ORIGIN at the beginning, then in the case of executables, it is the directory containing the executable, and in the case of libraries, it is the directory of the executable that loaded them. You can see how this is useful: it allows OpenOffice to be installed anywhere in the filesystem, and binaries can still find their internal dependencies, because their paths are relative to wherever the executable is, instead of some hardcoded location. In theory, you pass these options to the compiler when linking: -Wl,-z,origin -Wl,-rpath,$ORIGIN where -Wl,-z,origin enables the use of $ORIGIN in the path, and -Wl,-rpath,$ORIGIN specifies the path, in this case being the directory containing the executable. In practice, however, getting that "$" past dmake and 3 layers of shell quoting and escaping, is impossibly difficult. > > > 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. > > 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 hope this helps making my intentions at the time more clear now. > Thank you for the efforts you are putting into this issue! > Thank you :). > > Best regards, > -- > Arrigo > > Regards Damjan
