ldd:FATAL: Unresolved symbol “getopt_long” called from Executable - using compiled binaries for QNX on arm. Why?

Question

The Blackberry Playbook has formally reached EOL(april 2014), but I've installed BGShell, BGSSH-SCP-SFTP, and Term48 on it. So I have some ksh-like shell it seems with things like GNU awk 3.1.5, sed 4.1.5, grep and python, with some other coreutils elements (but no tr) etc. I'm not root. Basically I can write in the Downloads directory or in the $HOME dir created by the shell apps (/accounts/1000/appdata/com.BGShell..blabla/data for instance) and I can't execute everything but I can generally run a script within the aforementioned constraints. The reason I'm interested is because this is QNX on cortex-A9.:

QNX localhost 6.6.0 2014/03/19-01:28:41EDT OMAP4430_ES2.2_HS_Winchester_Rev:07 armle

---

So I compiled some binaries by trying to leverage an old project¹. Many things need be changed for this to work but it is set up and is able to compile most targets(including gcc and coreutils-8.13)². To summarize, I compiled using many different variations of configure flags and older versions of some dev tools to avoid some errors. I've settled for something like:

CFLAGS="-march=armv7-a -marm -fno-strict-aliasing -mtune=cortex-a9 -O2 -pipe -fomit-frame-pointer -mlittle-endian"
AUTOMAKE=automake-1.11: AUTOCONF=: AUTOHEADER=: AUTORECONF=: ACLOCAL=aclocal-1.11: MAKEINFO=makeinfo-4.13a

with the arm-unknown-nto-qnx8.0.0eabi-gcc cross-compiler linked from the 10.3 SDK which sits inside the momentics IDE. The resulting binaries look like this:

ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), BuildID[md5/uuid]=41442b23fecda2d1d7cc5d2c68432a33, not stripped

---

But every one of them errors on the tablet with this message:

ldd:FATAL: Unresolved symbol "getopt_long" called from Executable

As I recompiled many times using different flags and always get that message, I'm thinking I maybe mislinked some other things than the compiler in the build scripts as it was geared for a prior sdk... (this is beyond my expertise but maybe something about garbage collecting i.e. collect?). Or is it the exotic configuration on the target platform?

A million things could have gone wrong here because of the setup(and inexperience) but I'm looking for some clues so is there any specific thing I should understand from such an error and how can I backtrack the problem generally?

---

^{1. In summary it is a bunch of scripts to fetch, patch, compile, install to some dir then bundle that dir to one zip file then spawn a cute ruby webrick server and you use the tablet to download the script and the archive from it(I don't use it for the archive at 250mb, I just use some web file host and the browser).}

^{2. I've removed the ruby, file, and ruby targets from the top level build configuration.}

Answer 1

This is about confusing two different SDK¹. getopt_long exists on QNX6.6. But the libc version on the Playbook doesn't have that as it has an earlier version of /proc. The error would have never happened if I had installed the Playbook OS Native SDK v2.1.0 instead of blindly following the link in the project, which will install the Native SDK v10.3 with the 2.1 IDE for BB10. The project's information is clear but the link doesn't link to the proper SDK. So what I ended up with were most likely binaries made to run on the BB10 but on a device which doesn't exactly have the same infrastructure. Interestingly something like grep would work but refused to answer to --version i.e. a long option when compiled with the BB SDK...

---

But with the proper SDK there is no issue. Most targets have been recompiled². This is all happening on Arch Linux x84_64 where multilib repositories have been enabled(and many lib32- packages pulled). This is the build.sh configuration block I have used for gcc³:

CONFIGURE_CMD="$EXECDIR/gcc/configure
           --host=$PBHOSTARCH 
           --build=$PBBUILDARCH 
           --target=$PBTARGETARCH 
           --srcdir=$EXECDIR/gcc 
           --with-as=ntoarm-as 
           --with-ld=ntoarm-ld 
           --with-sysroot=$BBTOOLS/target/qnx6/ 
           --disable-werror 
           --prefix=$DESTDIR 
           --exec-prefix=$DESTDIR 
           --enable-cheaders=c 
           --enable-languages=c 
           --enable-threads=posix 
           --disable-nls
           --disable-libssp 
           --disable-tls 
           --disable-libstdcxx-pch
           --disable-newlib-supplied-syscalls
           --enable-libmudflap 
           --enable-__cxa_atexit 
           --with-gxx-include-dir=$BBTOOLS/target/qnx6/usr/include 
           --enable-shared
           --disable-subdir-texinfo
           --enable-cross-compile
           --enable-shared
           CC=$PBTARGETARCH-gcc
           CFLAGS='-march=armv7-a -marm -fno-strict-aliasing -mtune=cortex-a9 -O2 -pipe -fomit-frame-pointer -mlittle-endian'
           LDFLAGS='-Wl,-s '
           MAKEOPTS="-j5"
           AUTOMAKE=automake-1.11: AUTOCONF=: AUTOHEADER=: AUTORECONF=: ACLOCAL=aclocal-1.11: MAKEINFO=makeinfo-4.13a

---

Both coreutils and gcc work and I have aliased ls and grep with the --color option:

At last a functional shell with tron my Playbook, which offers a rare insight into QNX!

---

^{1. Thanks to Ryan Mansfield @Foundry27 for the heads up and to @Emmanuel for the info!}

^{2. Excluded targets: file, man, ruby, findutils. The resulting archive was 80Mib and the ruby webrick server was used to deploy as intended.}

^{3. ...for both gcc and coreutils actually(adding to the defaults in the latter case). It is not clear that all options are required or even recommended. Every target can be built individually by launching the build.sh script in the appropriate bootstrap/target directory i.e. bootstrap/gcc/build.sh. The build environment(bbndk-env.sh) must have been sourced once by the global top build.sh script using the -b option i.e. build.sh -b /path/to/bbndk-2.10. Sources are fetched to the work/target directories where they're built. If a build succeeds and no options is given(see lib.sh in the project root dir), it gets added to the pbhome directory structure which will be zipped into an archive(which will be deployed to your $HOME dir on the device running BGShell). Also note the reference to Darwin in lib.sh which I changed to x86_64 in my case. Otherwise nothing has been altered from the original project configuration i.e. arm-unknown-nto-qnx6.5.0eabi(as opposed to using the 8.0.0 version with the BB10.3 SDK like in the Q.). So it is very easy to compile once we weed out the few problematic targets.}