Syntax error: word unexpected (expecting ")") when running remotely but no problem running locally

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.