Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > From: "Theo de Raadt" <dera...@openbsd.org> > > Date: Sun, 03 Mar 2024 08:20:33 -0700 > > > > It almost feels as if libc.so equivelancy should be closer to > > _dl_find_shlib(), > > > > (in particular, meaning searchpath[0] in _dl_find_shlib() coming > > from lpath in _dl_load_shlib() > > > > Is testing for this in loader.c not the right place, and that > > code should be moved to a deeper place, reached by more variations? > > Yes, the diff below would make more sense. Anyway, probably something > to do after the next release? > > > The thing that would break is if someone dlopen() of > > "libc.so.not-a-system-library", and that is a real .so but not a real > > full libc; imagine it just contains 1 stub function which isn't a > > system call. it would now fail to load that stub function. So maybe > > it is better if we force the applications to request "libc.so".
No, I'm scared because this diff still converts "libc.so.tinysomething" with reference to the preloaded "libc.so". I think stuart's diff to python is safer.
