bluca,
@bluca@fosstodon.org avatar

Alright, this took some team effort but in git main we are now at:

$ lddtree build/libsystemd.so.0
build/libsystemd.so.0 (interpreter => None)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

for a full-feature build, down 5 libs which are now dlopened on demand. Last one, libcap, will need to be swapped for some ioctls which won't happen for this release.

codonell,

@bluca Congratulations! If dlopen() doesn't do what it says on the tin you know where to find us 😃

bluca,
@bluca@fosstodon.org avatar

@codonell thanks - seems to be working well!
If some company had a pile of cash to throw at this, especially in light of the 'xz' situation, it would be really nice if we could get support for OSX-like lazy loading/resolving of shared libraries, so that they are loaded only after the first symbol is actually called. IIRC dylibs on OSX have this feature since forever

codonell,

@bluca Yes, we don't defer as much as possible with -Wl,z,lazy (for semantic reasons). The difficulty has been in hardening the in-memory process image from attack. Delaying loading means we would need some novel way to segregate those control structures AND keep the same security features. RELRO took the low-cost high-value approach of immediate binding and hardening.

bluca,
@bluca@fosstodon.org avatar

@codonell yep, hardening becomes more difficult, no idea how they solve that on OSX. Another nice feature of dylibs is that AFAIK you can detect when such a lazy loaded library is not available and fallback, like we do when dlopen fails, which is perfect for optional features

codonell,

@bluca Do you have any pointers to these features on OSX? You would have to have a way for a compiled function call to fail, and the language has to have semantics for that.

bluca,
@bluca@fosstodon.org avatar

@codonell afraid not, as it's hearsay from @pid_eins 😃 iirc you can simply check if a function exists before calling it, but again all second-hand knowledge, never did OSX development work myself

pid_eins,
@pid_eins@mastodon.social avatar

@bluca @codonell Not a MaOS person, but the -weak_library switch to the MacOS linker is what creates a weak link supposedly, where the library doesn't have to exist.

The MachO header then ends up with an LC_LOAD_WEAK_DYLIB instead of a regular LC_LOAD_DYLIB entry for the library.

Note that the symbols simply become NULL if the library cannot be found, exactly like with the existing ELF weak symbols. The only difference really is that the whole library is allowed to be missing if this is used

pid_eins,
@pid_eins@mastodon.social avatar

@bluca @codonell … and not just some specific symbols, like with the existing ELF weak symbols.

Applications still have to explicitly check if a symbol is non-NULL before using it. And errors are not propagated afaics.

Googling LC_LOAD_WEAK_DYLIB and -weak_library reveals some docs, but they aren't really that great I'd say.

I have never used MacOS in my life, I just try to follow what the other OSes do, and this popped up somewhere, and I quite liked it and it stuck in my head ever since.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • Durango
  • DreamBathrooms
  • khanakhh
  • GTA5RPClips
  • osvaldo12
  • magazineikmin
  • mdbf
  • InstantRegret
  • rosin
  • Youngstown
  • slotface
  • everett
  • kavyap
  • ngwrru68w68
  • megavids
  • modclub
  • tester
  • tacticalgear
  • cubers
  • thenastyranch
  • cisconetworking
  • ethstaker
  • Leos
  • provamag3
  • normalnudes
  • anitta
  • JUstTest
  • lostlight
  • All magazines