Subject: Re: newlock2 and binary compatibility
To: Martijn van Buul <email@example.com>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 03/02/2007 14:04:43
Content-Type: text/plain; charset=us-ascii
On Fri, Mar 02, 2007 at 08:47:43AM +0000, Martijn van Buul wrote:
> It seems that since the merge of newlock2, -current is no longer binary
> compatible with 4.0_BETA2, 3.* and 2.* binaries. With the merge, several
> syscalls have been removed, and no emulation is in place. I stumbled=20
> across this while trying to cross-compile i386 NetBSD-4.0_BETA2 packages
> on my -current amd64 host, using a pkg_comp chroot. This fails during
> the configuration phase of databases/openldap-client, for example,
> as the configure script tries to run a small pthread test program, which
> fails with a "system call not implemented."
> In my specific case, I can probably work around things by trying to
> shoehorn -current's libpthread into 4.0_BETA2, but it's not elegant.
That's probably what you want to do. You will also need add syscall stubs=
for the system calls the new libpthread uses. While they are in libc=20
12.150 & later, you may contaminate your 4.X environment with other stuff.
> Is a "true" solution actually possible? I don't know the old scheduler
> activation syscall interface nor the newlock2 one well enough to figure o=
> if emulation would be feasible, but it would be nice of something could
> be done.
The problem is that the sa code won't work w/o biglock (and sometimes not
even then). And no one came up with a fix.
The main compat idea was that all you need is a libpthread that=20
corresponds to your kernel. chroot environments, though, are more=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----