NetBSD Problem Report #60394

From www@netbsd.org  Thu Jul  2 18:33:57 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "R13" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8C4131A923A
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  2 Jul 2026 18:33:57 +0000 (UTC)
Message-Id: <20260702182427.B35A41A9244@mollari.NetBSD.org>
Date: Thu,  2 Jul 2026 18:24:27 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: LD_PRELOAD for compat ld.elf_so-XXX
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60394
>Category:       bin
>Synopsis:       LD_PRELOAD for compat ld.elf_so-XXX
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 02 18:35:00 +0000 2026
>Last-Modified:  Fri Jul 03 16:10:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The NetKver Foundation
>Environment:
>Description:

	Tried building gcc15 with libkver.so to force a particular
	uname (so I can use the same machine to build packages for 9,
	10, and 11), and it failed with:

configure:3748: checking whether we are cross compiling
configure:3756: /tmp/pkgbuild/lang/gcc15/work/build/./gcc/xgcc -B/tmp/pkgbuild/lang/gcc15/work/build/./gcc/ -B/pkg/2026Q2/gcc15/x86_64--netbsd/bin/ -B/pkg/2026Q2/gcc15/x86_64--netbsd/lib/../lib/i386 -B/pkg/2026Q2/gcc15/x86_64--netbsd/lib/ -isystem /pkg/2026Q2/gcc15/x86_64--netbsd/include -isystem /pkg/2026Q2/gcc15/x86_64--netbsd/sys-include -fno-checking  -m32 -o conftest -g -O2 -I/usr/include  -Wl,-R/pkg/2026Q2/lib -Wl,-zrelro conftest.c  >&5
configure:3760: $? = 0
configure:3767: ./conftest
/pbulk/pkg/lib/libkver.so: invalid ELF class 2; expected 1
configure:3771: $? = 1
configure:3778: error: in `/tmp/pkgbuild/lang/gcc15/work/build/x86_64--netbsd/32/libgcc':
configure:3782: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

	Trouble is that libkver.so is an amd64 elf file, and that can't
	be preloaded with LD_PRELOAD when running a -m32 executable.

>How-To-Repeat:

	try to use libkver.so with a compat32 executable

>Fix:

	Add LD_PRELOAD_<ABI> or something?

	(Convince the world to look at /etc/release instead of uname to
	find the OS version?)

>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/60394: LD_PRELOAD for compat ld.elf_so-XXX
Date: Fri, 03 Jul 2026 23:06:08 +0700

     Date:        Thu,  2 Jul 2026 18:35:00 +0000 (UTC)
     From:        "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20260702183500.B651D1A9244@mollari.NetBSD.org>

   | 	(Convince the world to look at /etc/release instead of uname to
   | 	find the OS version?)

 We probably should have uname -r use the /etc/release value to get its
 version info, which really means making uname(3) use something
 other than kern.osrelease (perhaps user.osrelease ?) for the release
 field of struct utsname, which like the other user.xxx sysctl vars
 would be baked into libc, and hence easily set to the same thing which
 is stored in /etc/release which is itself too messy to parse to expect
 anything to actually do that.

 We could add a uname -k to get the kernel version, which in practice,
 almost nothing should ever be looking at (and so which probably does
 not need a struct utsname field).

 kre

Home	PR Database Search