propeller-elf-gcc compilation on Jetson TK1

I am attempting to compile my C source code for the Propeller Activity Board on a Jetson TK1 (armv7l) running Ubuntu 12.04. In my case, I need to forgo using the GUI/SimpleIDE, so I am trying to compile from the command line. I figured the Raspberry Pi (armv6) SimpleIDE binaries might compatible with the TK1 but I have run into some strange stuff.

First off, this is the source for the SimpleIDE I installed. Running "simpleide" won't work because of a Qt incompatibility. I don't care because the whole point is to not use the GUI. After this, from /opt/parallax/bin I can run propeller-elf-gcc, propeller-load, etc. Using ELF and binary files created by actually running SimpleIDE on my Mac using the following source code, propeller-load on the TK1 works correctly. My program runs and the serial terminal output is correct. Therefore I assume the issue must be with the compiler: propeller-elf-gcc. The source is as follows...

But when I run this version, a single, non-alphanumeric byte gets spit out to the terminal followed by nothing else. The version compiled on the Mac, loaded on by the TK1, instead spits out two non-alphanumeric values and then starts the count correctly. Just for comparison, the working binary is 9212 bytes in size.

I cannot find any reference to a "sys-include" folder on the TK1, nor my Mac. Does anyone know where this comes from?

Soon I will build from source both libfdserial and libsimpletext on the TK1. I've only used the included .a files up until now and I feel that I am running out of places to look for the source of this problem. Simplifying the source even further be removing dependence on those two libs and simply printing with printf builds just fine on the TK1, so I am stumped.

Thank you, David. I decided to take a step back and try to get this all to work on my Raspberry Pi3 B. To my surprise, it doesn't work there either! I can build and run a simplified example of hello.c that uses printf instead of fdserial and it works fine on both the Pi and TK1. It's only when I use the ELF file with links to the Simple Libraries that it fails to produce something that runs correctly.

I have tried the latest version of the binaries for the Pi that you linked. As a side note, I did not use anything from the second download link because it doesn't seem to contain the Simple Libraries (libfdserial and libsimpletext) that I need.

No new luck using the new binaries, even after using them to rebuild the latest release of libfdserial and libsimpletext from source.

At this point, I'm convinced that the problem is with the Simple Libraries as, without them, everything works just fine. I just can't seem to find any mention of someone having a similar issue, even with the Pi.

I think the (dis)similarity in gdb output for the different cases is interesting. For the simplified hello.c version they look relatively similar but for the one with fdserial the differences seem very odd.

I'm afraid that all of those disassemblies are bogus (the "<unrecognized instruction>" clinches this, but the high proportion of conditional instructions was also a clue). It almost looks like gdb has gotten confused about whether the code was compressed (CMM) or not.

Getting back to the original problem, I have heard that some of the Simple Libraries have trouble with new PropGCC versions (which is one reason, I think, that the official PropGCC release is so old). I don't know any more details, though.

I have tried the latest version of the binaries for the Pi that you linked. As a side note, I did not use anything from the second download link because it doesn't seem to contain the Simple Libraries (libfdserial and libsimpletext) that I need.

When I compile the Simple libraries, I put all of the different objects into a single static archive: libSimple.a. Look for a library by that name in the second download and try linking against that. So long as you link with "-Wl,--gc-sections", you should get the same size binary because the files in the library were compiled with "-ffunction-sections -fdata-sections". A few bytes difference will of course be expected because the compiler is different.

Getting back to the original problem, I have heard that some of the Simple Libraries have trouble with new PropGCC versions (which is one reason, I think, that the official PropGCC release is so old). I don't know any more details, though.

I did some work a while ago to pinpoint at least one of those problems, and I haven't been able to find it again in either the PropGCC or Simple Libraries issue trackers on GitHub. Perhaps I talked through the issue in a forum thread here... not sure.

Anyway, what's weird to me (and the reason I don't understand this problem in the first place) is that Falimond used the PropGCC and Simple libraries shipped with SimpleIDE in his original post. Those should have been compatible. It makes sense that his second test - new version of PropGCC + old version of Simple libs - failed because that seems to be the same problem I (supposedly) documented a while ago. But his first test... that's just weird .