Thanks for all the work that has gone into making Cinder work on Linux. I have built and run various samples on the TK1 using gcc, but would like to use clang for my own project, as I take advantage of some C++14 features (mainly std::make_unique) and would like to have a consistent compiler between Linux and OSX.
I am running into trouble when building the Cinder library with clang on the TK1. The TK1’s apt-get has an outdated version of clang, so we need to download a prebuilt binary, as discussed in the wiki instructions. Once downloaded, I copied the contents of the clang directory to /usr/local/ so I could run the clang/clang++ commands on my TK1. Unfortunately, they aren’t able to find their own standard library when building, so compiling the first Cinder file (Area.cpp) throws a fatal compile error in the gcc-4.8 standard library (no member named 'gets' in the global namespace).
I assume there is some step I can take to install libc++ on my TK1 such that clang will be able to find it and build against it. I just don’t know how to take that step.
I wouldn’t recommend going down the libc++ road on Linux. The main problem is that libstdc++ and libc++ are still not 100% compatible. This means that you can run in a lot of issues if you try to mix binaries that where compiled with different versions of the standard library. The safest path would be to stick with the default for each platform, libc++ for OS X and libstdc++ for Linux.
Clang on Linux should work nicely with libstdc++ but it seems you have run into a known ( see here for example ) bug that manifests with certain version combinations of libstdc++ and Clang.
What I would recommend and this is on the top of my head since I haven’t been on the TK1 for a while would be to try first to install a newer version of gcc .
4.8 that ships with the TK1 is really old so I would at least try to install 4.9 which should be as easy as :
Just make sure you that the symlink from /usr/bin/g++ then points to /usr/bin/g++4.9 ( if not create it yourself ) and retry to compile Cinder with Clang.
Hopefully the libstdc++ version that ships with g++4.9 will do the trick for you.
That update (which did require manual symlinking) allowed me to get close to compiling with the same code on Ubuntu as OSX. I think I’m down to managing header includes at this point.
After updating, I made sure to use c++14 with cmake (still the older flag in this version of g++) and my earlier errors/werrors went away.
Alright, I able compile and link executable files using clang. However, it is not possible to run the built executable.
I tried building both my new program and the ParticleSphereGPU sample with clang as follows:
cd proj/cmake
mkdir build/Release && cd build/Release
cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_FLAGS="-std=c++14"
make -j4
The resulting executable won’t run. ./application => “Permission denied” sudo ./application => "command not found"
double-clicking in file browser => “Could not display ‘application’. There is no application installed for ‘executable’ files.”
I tried compiling with and without the c++14 flag with no difference. I rebuilt Cinder with clang before compiling the applications.
Is this possibly caused by my installation of clang living in /usr/local/bin? Is there some way to raise the permission level on clang so it outputs runnable applications? Sample applications built with gcc worked fine.
For sanity, I ran the file command on my applications, which shows that they are ELF 32-bit LSB executable, ARM applications. This matches the results of file for gcc and clang, so they appear to be properly compiled applications. sudo chmod a+x has no noticeable effect on the applications.
The non-executable executables were compiled on external media (an SD card) rather than the built-in disk on the TK1, while the samples that worked were built in a clone of cinder directly on the desktop. Could that be a source of errors? I was hoping to spare the device the huge amount of space needed for all of my project’s git repo and submodules.
UPDATE:
If I build everything on the TK1’s main disk, it is able to run. I would love to know why that’s the case, but at the moment I’m satisfied that it works.
The errors you get when trying to run directly on the SD card are most probably related to the way it is mounted into the filesystem. Not much experience on this but it seems related to the SD card being mounted with the noexec option and/or as FAT which means that the permissions are set during mounting and cannot be changed afterwards from commands like chmod.
It seems that there are some tricks around for overcoming this issue though. Most common seems to be to modify the umask in fstab .
This should provide you with some hints to start with.