Greg Earle wrote:
> On Jan 9, 2005, at 4:46 AM, sigsegv@rambler.ru wrote:
> 
>> Still, I hit the same problem, binaries under /emul/netbsd32/bin
>> execute OK, but the ones under /emul/netbsd32/usr/bin don't.
>> Below are the traces for two sample executables (both are 32-bit
>> dynamically linked sparc executables), seems to be that for one
>> executable the OS knows how to use 32-bit emulation, but for the
>> other one it doesn't.  I don't really know what's going on the
>> kernel level, so any help/suggestions would be much appreciated :-)
>>
>> This is what I get from executing /emul/netbsd32/bin/date:
>>
>> Sun Jan  9 12:19:58 UTC 2005
>>    360 ktruss   emul(netbsd)
>>    360 ktruss   fktrace                            = 0
>>    360 date     emul(netbsd32)
>>    360 date     netbsd32_execve("/emul/netbsd32/bin/date", 
>> 0xffffffffffffd9e0, 0xffffffffffffd9f0) JUSTRETURN
>>
>> This is what I get from executing /emul/netbsd32/usr/bin/id:
>>
>>  754 ktruss   emul(netbsd)
>>    754 ktruss   fktrace                            = 0
>>    754 ktruss   execve("/emul/netbsd32/usr/bin/id",
>> 0xffffffffffffd9e0, 0xffffffffffffd9f0) Err#8 ENOEXEC
> 
> 
> Well, from execve(2):
> 
>      [ENOEXEC]     The new process file has the appropriate access 
> permission,
>                    but has an invalid magic number in its header.
> 
> What is the output of
> 
> file /emul/netbsd32/bin/date /emul/netbsd32/usr/bin/id
> 
> and
> 
> ldd /emul/netbsd32/bin/date /emul/netbsd32/usr/bin/id
> 
> ?
> 
> One thing I notice is that "/bin/date" on my 32-bit NetBSD/SPARC (not
> NetBSD/SPARC64) system is statically-linked, whereas "/usr/bin/id" is.
> 
>     - Greg
> 
> 

I got this part fixed now, Martin replied to me, suggesting that 
absolute symlinks in /emul/netbsd32/usr/lib and 
/emul/netbsd32/usr/execlib pointing to /lib and /libexec were the likely 
cause of the problem. Either running 'chroot /emul/netbsd32 /bin/sh' or 
fixing symlinks to make them relative fixes the problem.