QNX 4.24G Watcom 10.6 with Beta/970211.wcc.update.tar.F socket3r.lib Nov21 1996.
As of perl5.8.1 there is at least one test still failing.
Some tests may complain under known circumstances.
See below and hints/qnx.sh for more information.
Under QNX 6.2.0 there are still a few tests which fail. See below and hints/qnx.sh for more information.
If you wish to compile with the Socket extension, you need to have the TCP/IP toolkit, and you need to make sure that -lsocket locates the correct copy of socket3r.lib. Beware that the Watcom compiler ships with a stub version of socket3r.lib which has very little functionality. Also beware the order in which wlink searches directories for libraries. You may have /usr/lib/socket3r.lib pointing to the correct library, but wlink may pick up /usr/watcom/10.6/usr/lib/socket3r.lib instead. Make sure they both point to the correct library, that is, /usr/tcptk/current/usr/lib/socket3r.lib.
The following tests may report errors under QNX4:
dist/Cwd/Cwd.t will complain if `pwd` and cwd don't give the same results. cwd calls `fullpath -t`, so if you cd `fullpath -t` before running the test, it will pass.
lib/File/Find/taint.t will complain if '.' is in your PATH. The PATH test is triggered because cwd calls `fullpath -t`.
ext/IO/lib/IO/t/io_sock.t: Subtests 14 and 22 are skipped due to the fact that the functionality to read back the non-blocking status of a socket is not implemented in QNX's TCP/IP. This has been reported to QNX and it may work with later versions of TCP/IP.
t/io/tell.t: Subtest 27 is failing. We are still investigating.
op/sprintf.........................FAILED at test 91 lib/Benchmark......................FAILED at test 26
This is due to a bug in the C library's printf routine. printf(``'%e''', 0. ) produces '0.000000e+0', but ANSI requires '0.000000e+00'. QNX has acknowledged the bug.
Setting up a cross-compilation environment
You can download the NDK from <http://developer.blackberry.com/native/downloads/>.
See <http://developer.blackberry.com/native/documentation/cascades/getting_started/setting_up.html> for instructions to set up your device prior to attempting anything else.
Once you've installed the NDK and set up your device, all that's left to do is setting up the device and the cross-compilation environment. Blackberry provides a script, "bbndk-env.sh" (occasionally named something like "bbndk-env_10_1_0_4828.sh") which can be used to do this. However, there's a bit of a snag that we have to work through: The script modifies PATH so that 'gcc' or 'ar' point to their cross-compilation equivalents, which screws over the build process.
So instead you'll want to do something like this:
$ orig_path=$PATH
$ source $location_of_bbndk/bbndk-env*.sh
$ export PATH="$orig_path:$PATH"
Besides putting the cross-compiler and the rest of the toolchain in your PATH, this will also provide the QNX_TARGET variable, which we will pass to Configure through -Dsysroot.
Preparing the target system
It's quite possible that the target system doesn't have a readily available /tmp, so it's generall safer to do something like this:
$ ssh $TARGETUSER@$TARGETHOST 'rm -rf perl; mkdir perl; mkdir perl/tmp' $ export TARGETDIR=`ssh $TARGETUSER@$TARGETHOST pwd`/perl $ export TARGETENV="export TMPDIR=$TARGETDIR/tmp; "
Later on, we'll pass this to Configure through -Dtargetenv
Calling Configure
If you are targetting an ARM device --- which currently includes the vast majority of phones and tablets --- you'll want to pass -Dcc=arm-unknown-nto-qnx8.0.0eabi-gcc to Configure. Alternatively, if you are targetting an x86 device, or using the simulator provided with the NDK, you should specify -Dcc=ntox86-gcc instead.
A sample Configure invocation looks something like this:
./Configure -des -Dusecrosscompile \
-Dsysroot=$QNX_TARGET \
-Dtargetdir=$TARGETDIR \
-Dtargetenv="$TARGETENV" \
-Dcc=ntox86-gcc \
-Dtarghost=... # Usual cross-compilation options