Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > 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()
> >
> From: "Theo de Raadt"
> 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
Stuart Henderson wrote:
> +allow dlopen() to search for libc rather than parsing ldconfig -r to
> +decide on a version number.
> +
> +(would this make sense for all libraries? I'm not sure exactly what
> +parameters this might be called with, whether it's just a bare name or
> +could have a
On 2024/03/03 15:21, Stuart Henderson wrote:
> On 2024/03/03 07:59, Theo de Raadt wrote:
> > Does it work if this is modified to just ask for "libc.so"?
>
> Yes. Conservative approach just doing this for libc:
oh, we need to update the installed list-of-changes file too,
and diff updated to
On 2024/03/03 07:59, Theo de Raadt wrote:
> Does it work if this is modified to just ask for "libc.so"?
Yes. Conservative approach just doing this for libc:
Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
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
> Date: Sun, 3 Mar 2024 14:35:09 +
> From: Stuart Henderson
>
> On 2024/03/03 14:29, Stuart Henderson wrote:
> > On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > >
Stuart Henderson wrote:
> > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> > (without a specific version number). ld.so is picking the latest and
> > loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> > error.
>
> oh, it's not ld.so which is picking
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.
Time to explain the msyscall thing a bit.
msyscall(2) will go away after
On 2024/03/03 14:29, Stuart Henderson wrote:
> On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > > Is this a situation where two libc's are being loaded into the address
> > >
On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > Is this a situation where two libc's are being loaded into the address
> > > space? And the 2nd one is refused for pinsyscalls &
> Date: Sun, 3 Mar 2024 13:19:36 +
> From: Lucas Gabriel Vuotto
>
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > Is this a situation where two libc's are being loaded into the address
> > > space? And the 2nd one is
On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> On 2024/03/02 14:46, Theo de Raadt wrote:
> > Is this a situation where two libc's are being loaded into the address
> > space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
>
> It seems the most likely cause.
On 2024/03/02 14:46, Theo de Raadt wrote:
> Is this a situation where two libc's are being loaded into the address
> space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
It seems the most likely cause. Console output from running with
LD_DEBUG set in the environment would
Is this a situation where two libc's are being loaded into the address
space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
We solved that for most programs. Something special about python?
Stuart Henderson wrote:
> On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote:
> > gajim
On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote:
> gajim is reporting a msyscall error on launch since today's snapshot.
This is likely to be fixed by updating to packages built against the new
libc version when they're available.
> OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024
>
On Sat, Mar 02, 2024 at 08:32:04PM +, Lucas Gabriel Vuotto wrote:
> Hello,
>
> gajim is reporting a msyscall error on launch since today's snapshot.
>
> OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>
17 matches
Mail list logo
