Howdy. Whilst playing with the Nto 2.11 beta release for QNX4 (you know, that
developer thingie), I ran into an “undocumented feature” (potential bug) with
mkifs. It seems that if you try to make entries in your build file that point
to a startup file in your current directory instead of wherever mkifs normally
wants to look for such files (/usr/nto/x86/lib or /x86/boot/sys for QNX4 or RtP
respectively), it produces an unusable startup module. For example, here’s my
build file:
----------- ifs.build ----------
[virtual=x86,nobios +compress] boot = {
startup-enc
PATH=.:/proc/boot procnto
}
[+script] startup-script = {
devc-ser8250 -c7372800 -b19200 3f8,4 400,12 408,13 410,14 418,15 &
reopen /dev/ser2
stty sane +edit
SYSNAME=nto
TERM=qansi
[+session] sh
}
[type=link] /tmp=/dev/shmem
[type=link] /dev/console=/dev/ser2
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so.1
libc.so
[data=c]
Executables must currently be below this line
sh=fesh
devc-ser8250
stty
pidin
ls
----------- end of ifs.build -------------
If you change the second line from “startup-enc” to
“startup-enc=./startup-enc”, startup_vaddr in the header changes from 0x3C58
(which works fine) to 0x26998 (which reboots when jumped to in the IPL). mkifs
doesn’t complain about anything either way, it’s just that one way works, and
the other way causes you to swear a lot. 
Behavior is identical (but off by
8 bytes) for the QNX4 hosted development environment, as well as mkifs on RtP.
Even if there’s literature somewhere that says “Don’t do that”, it would be
nice if mkifs would complain to you about relative pathnames or something.
-Warren
