I've read plenty of discussions on various possibilities why such a thing can happen however all are about some missing library on the system where the binaries are deployed. This is not my case.

I have a Raspberry Pi 2 with latest Raspbian and a Debian 8 notebook with x86-64 Intel architecture and a Qt Creator 3.2.1 installed on the second, where I cross-compile my binaries using the arm-linux-gnueabihf-g++ (using the Emdebian repository). I am not using the optimized compiler provided in the official RPi github repository.

Here is the prequal to my problem. After much sweat and swearing I managed to cross-compile and deploy my binary from the notebook onto the RPi2. And here is the problem:

  • When I try to run my binary from withing Qt Creator (which connects to the RPi2 via SSH, transfers files via SFTP and is logged in as my only RPi user (hence "access issue" is excluded here for sure)) on my notebook I get:

    Syntax error: word unexpected (expecting ")")

  • When I try to run my binary directly on my RPi it runs without a single issue.

As I've posted on stackoverflow my code contains only pure C++ writing a text file to the directory where the binary is upon execution. Nothing weird going on there.

So the main question here is is this a Qt Creator related issue or something that goes much deeper? I have no idea how exactly Qt Creator internally runs the binary on the remote system. If I connect via SSH to my RPi via terminal and execute the binary it works fine. So it has to do something with the way Qt Creator executes it. Note that executing the ARM binary on my notebook returns what we all expect (RPiCrossCompileRemoteTest is the name of my binary):

bash: ./RPiCrossCompileRemoteTest: cannot execute binary file: Exec format error

So Qt Creator neither starts the binary straight onto the RPi nor tries to start it on my notebook (otherwise it would have given me the format error from above).

Any ideas how I can proceed towards resolving this? I have been fighting with this issue for a couple of days all in vain. :-/

EDIT: As suggested by @steve running ldd on both executables:

  • On the RPi:

    /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x76f84000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ea3000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e32000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76e0a000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76cda000)
    /lib/ld-linux-armhf.so.3 (0x76f91000)
  • On the notebook:

    not a dynamic executable

The second one is correct. I don't know that to think about the first one though.

Also I used the g++-arm-linux-gnueabihf that is in my Raspbian to compile a new binary in order to compare both. The output of ldd is literally the same with the small exception that I have different memory addresses (the HEX numbers in brackets) where the libs will be loaded.

EDIT 2: As @gogoud suggested:

  • Changed to key authentification
  • Checked shell on my RPi - it is bash
  • Added RequestTTY=force to a newly created ~/.ssh/config

No change at all. Same old story. I did however notice the actual exit code: 2. From TLDP:

2: Misuse of shell builtins (according to Bash documentation) Example: empty_function() {} Comments: Missing keyword or command, or permission problem (and diff return code on a failed binary file comparison).

This doesn't make sense for my binary (I think). I have also checked the permissions on it: drwxr-xr-x. This means that all can execute and read it.


Sounds to me like QCreator is using the wrong shell type on your RPi2? The error message suggests that the shell is unable to create an array type, which might indicate it is running dash say instead of bash.

If this is the case, you need to find a way to 'force' an ssh login on RPi2 to use a given shell (probably bash). One limited way is to use forced command(s) with key-based, not password-based, ssh login. However this would limit this user to running a single set of commands at login.

You could try using chsh on RPi2 for the relevant user to set the default shell to /bin/bash? If it is already set to this then you could try adding RequestTTY=force to ~/.ssh/config for the client user on your local machine (on which you run QtCreator).

  • Changed to key authentification (that was such a pain in the butt :-/). No need for chsh since echo $SHELL on my RPi returns /bin/bash. Adding RequestTTY=force to a newly created config inside my notebook's .ssh didn't change a thing. I did however finally look closer at the error I get in the terminal that pops up when I try to run my application inside Qt Creator: it returns code 2 -> (quote; bash documentation) "Misuse of shell builtins". The problem is that this code might be misleading due to the absence of standardization of such codes. It might mean something completely different. – rbaleksandar Aug 19 '15 at 9:31
  • I've edited my question (see EDIT2). – rbaleksandar Aug 19 '15 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.