Hi, Libor, On Fri, 12 Mar 2021, Libor Pechacek wrote:
Nicolai reminded me about the magic $ORIGIN token. The demo works even better with that one.
TIL $ORIGIN... Thanks! :)
Encouraged by the success, I've entertained the idea of getting rid of the LD_PRELOAD. So, I tried:
$ gcc -Wl,-rpath,\$ORIGIN -Wl,-rpath,/data/src/libpulp/lib/.libs -L. \ -L ../lib/.libs/ -o main main.c -lworkload -lpulp
And, voilà! I can just run "main" and live patch it without any extra hassle.
Before I start exploring this possibility further, do you think that it's OK to leverage the dynamic linker for preloading libpulp?
Do you mean the use of "-lpulp", so you get rid of LD_PRELOAD? I don't see any problems with it, though I should add that ld's -as-needed flag (which is used by default in OBS builds) would break that, because your library (or any to-be-made-livepatchable library, for that matter) doesn't actually depend on libpulp.so; thus, you might need to use: -Wl,-no-as-needed -lpulp. I'm not sure what's the main purpose of using LD_PRELOAD. The only advantages (as compared to hard-coding libpulp.so.N into NEEDED entries in the Elf file) I can think of are: 1. one less package on your system if you don't want live-patching; 2. Being able to selectively enable live-patches on a process-by-process basis.
I can imagine users may want to build "live patchable" applications, and perhaps also patchable shared libraries. In that can thay may want reference libpulp from the shared library.
I think I see what you mean... You would like to be able to create a package with a library that is live-patchable out-of-the-box, right? For instance, if someone installs your package for libworkload, then all projects linked against it will produce live-patchable applications which, when executed, start live-patchable processes (even if LD_PRELOAD is not used). Is that what you mean? If so, I don't know how end-users want libpulp to behave... Not yet. Your use case is a good hint for me, though... Initially, I thought everybody would prefer the LD_PRELOAD approach, so the package at OBS (home:ULP) doesn't even distributes libpulp.so in the development package (only libpulp.so.0 on the library package), as explained in the spec file: %install (...) # Remove .la and .so files. libpulp.so is not supposed to be linked # against any programs or libraries, but LD_PRELOAD'ed, so do not # distribute it, not even in the devel package. find %{buildroot}/%{_prefix} -name libpulp.la -delete find %{buildroot}/%{_prefix} -name libpulp.so -delete (lines 92-96 in https://build.opensuse.org/package/view_file/home:ULP/libpulp/libpulp.spec?e...) Perhaps that should go away, so that users can do like you and use -lpulp. Cheers, Gabriel