The following reply was made to PR port-sparc64/38949; it has been noted by
From: christos@xxxxxxxxxx (Christos Zoulas)
To: matthew green <mrg@xxxxxxxxxxxxx>
Cc: port-sparc64-maintainer@xxxxxxxxxx, netbsd-bugs@xxxxxxxxxx,
gnats-admin@xxxxxxxxxx, gnats-bugs@xxxxxxxxxx, raymond.meyer@xxxxxxxxxx
Subject: re: port-sparc64/38949 (under emul_netbsd32 on sparc64 some
applications die with segfault)
Date: Mon, 18 May 2009 18:10:55 -0400
On May 19, 7:42am, mrg@xxxxxxxxxxxxx (matthew green) wrote:
-- Subject: re: port-sparc64/38949 (under emul_netbsd32 on sparc64 some appli
| On May 19, 7:05am, mrg@xxxxxxxxxxxxx (matthew green) wrote:
| -- Subject: re: port-sparc64/38949 (under emul_netbsd32 on sparc64 some
| | hmm, what happens if you don't have /emul/netbsd32? ie, just copy
| | those /bin/ksh or /bin/sh files somewhere and run them as is.
| | /emul/netbsd32 is probably going to be going away as being used.
| | i haven't really thought deeply about this, but, i don't want to
| | keep two methods of 32 bit support around and the new one is much
| | better, so it's likely this will disappear.
| Static binaries are not supported then. Not that I will miss them but...
| Linux provides both.
| how does /emul/netbsd32 affect static binaries?
The /emul/netbsd32 userland portion of netbsd32 does not matter but the
kernel part matters for both. I think that the userland portion of
/emul/netbsd32 should be just handled by symlinks to the compat directories.