[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: port-sparc64/38949 (under emul_netbsd32 on sparc64 some applications die with segfault)
The following reply was made to PR port-sparc64/38949; it has been noted by
From: matthew green <mrg%eterna.com.au@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas)
Subject: re: port-sparc64/38949 (under emul_netbsd32 on sparc64 some
applications die with segfault)
Date: Tue, 19 May 2009 08:26:18 +1000
| On May 19, 7:05am, mrg%eterna.com.au@localhost (matthew green) wrote:
| -- Subject: re: port-sparc64/38949 (under emul_netbsd32 on sparc64
| | 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
| 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.
how does it matter? the new work i've done for 5.0 for sparc64/amd64
makes it not required at all, AFAIK. i do not have a /emul/netbsd32
on any of my machines anymore, and everything works for me on both
amd64 and sparc64.
"options COMPAT_NEBBSD32" itself is entirely necessary, but afaict,
it doesn't need to ever look in /emul/netbsd32 anymore.
Main Index |
Thread Index |