I compiled a universal C program on Xcode (v13) using clang 13 on macOS 12.
I found how to build a product for intel and arm64, but the issue is that when someone tries to execute it on a macOS 12.5 or even 13 for example, the following issue appears:
dyld[13504]: Library not loaded: #rpath/libclang_rt.asan_osx_dynamic.dylib
Reason: tried: [...]
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib' (no such file) [...]
So it appears that if someone tries to execute it on higher versions of macOS, it will fail because the program explicitly tries to find clang 13, whereas a different version is installed.
On Xcode, how can I embed everything necessary into the executable in order to be "future proof" ?
The C program is a single file.c
Related
I'm currently compiling sources using --coverage, with GCC. The generated .gcno files (and the instrumented libraries) are to be packed in a RPM and the code coverage evaluated on another, target platform.
Now, I'm having a problem getting the coverage data, because when I run the programs calling the instrumented code, I get messages telling me that I have a version mismatch. They look like:
".gcda:Version mismatch - expected A85R got B12R"
Now, I've seen this question: GCOV Version mismatch - expected 700e got 408R which says I must use the same toolchain when compiling and when executing the code.
I'm compiling using gcc 11.2.1, and gcov --version says the same thing, on the source platform.
On the target platform, gcc --version and gcov --version both give that very same version number.
The compiling and the testing is done on the same "physical" machine, but on different Docker containers. On both of them, the GCC version and gcov version are the same
I've done further testing: even on the Docker container where we compile, we cannot run the coverage, and get the same error. Or, to be more precise, when compiled using gcc 11, it will say "version mismatch". However, when compiled using gcc 8.5, it works.
The setup is that we have the GCC 11 toolset, which requires gcc 8.5 to install. By default, gcc 8.5 is enabled, and you have to use a script (provided by the gcc 11 toolset) to enable the later. That script updates different variables, like the PATH, LIBRARY_PATH, etc., to look at GCC 11 first.
However, I'm pretty sure it doesn't upgrade the libc.so library, and that it's the cause of the problem: I compiled two of our simplest libs (each of them having no dependencies whatsoever, except libc) with gcc 11, in coverage mode. Then I compiled a simple test program, without coverage, calling some functions from the two instrumented libs. I checked (with elfread -d), the program only links to these two libs (and libc).
Calling this test program while on the compilation container results in the Version mismatch error, which would lead me to conclude that our libc.so isn't compatible with gcc 11.
I wonder if there is a way to get a "native" gcc 11, instead of a "toolkit" package which has to be installed over a gcc 8.5 (my colleague in charge of creating the Docker containers tells me that for gcc 9 and above, there are only "toolkit" packages, requiring gcc 8.5 to install).
Our target architecture runs on Rocky Linux, and I think our development architecture is a Redhat, if it has any importance here.
I've tried compiling an SDL2 program on windows using mingw gcc in Code::Blocks, but the only way I can get the produced binary to work is by stripping the symbols with the -s option. Even with just a simple printf program, but only when SDL.h is included.
What is going wrong and how can I fix it?
Produced output differs depending on how the binary is run.
Using the terminal I get:
Program 'main.exe' failed to run: The specified executable is not a valid application for this OS platform
Using Code::Blocks to build and run, the produced binary runs, but without any output and exits immediately with:
Process terminated with status 32760
Looking up the status code produces no results, both in mingw and SDL2.
Trying to compile with -static causes a bunch of output with ld returned 1 exit status and Dwarf Error: Can't find .debug_ranges section.
This seems to imply that debug info is missing from the linked dll file as I understand it.
SDL2 is included and linked from the extracted SDL2-devel-2.24.0-mingw folder from the libsdl github releases.
The same errors can be reproduced by creating a SDL2 project with Code::Blocks and compiling the given code in debug and release, since only the release strips the symbols it runs fine, but the debug build does not. Enabling the -s option in debug produces a working binary.
Edit: Compiling SDL2 from source seems to have fixed the issue, so this seems to only be a problem with the precompiled binaries downloaded from the release page. I'm assuming it was because of the missing debug symbols, but it would be appreciated if anyone can confirm that this was the case and explain why stripping symbols creates a working binary?
Edit 2: The main problem seems to be with the outdated mingw compiler included with Code::Blocks which is on version 8.1.0. Using a more recent version of mingw64 such as 12.2.0 from mingw-w64 also fixes the issue.
I am trying to install Tensorflow Lite on Raspberry Pi Zero W. I followed the steps from the official website (https://www.tensorflow.org/lite/guide/build_cmake_arm). But I get the following error message:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: /home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc
-- Check for working C compiler: /home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -- broken
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"/home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_ed1a3/fast && /usr/bin/make -f CMakeFiles/cmTC_ed1a3.dir/build.make CMakeFiles/cmTC_ed1a3.dir/build
make[1]: Entering directory '/home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ed1a3.dir/testCCompiler.c.o
/home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -march=armv6 -mfpu=vfp -funsafe-math-optimizations -o CMakeFiles/cmTC_ed1a3.dir/testCCompiler.c.o -c /home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeTmp/testCCompiler.c
/home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc: 1: /home/pi/toolchains/arm-rpi-linux-gnueabihf/x64-gcc-6.5.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc: Syntax error: ")" unexpected
make[1]: *** [CMakeFiles/cmTC_ed1a3.dir/build.make:66: CMakeFiles/cmTC_ed1a3.dir/testCCompiler.c.o] Error 2
make[1]: Leaving directory '/home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_ed1a3/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:44 (project)
Configuring incomplete, errors occurred!
See also "/home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeOutput.log".
See also "/home/pi/Project/cmake-3.16.0/CMakeFiles/CMakeError.log".
Does anyone know how to fix the problem?
I ran into the same problem like you!
The instructions given at https://www.tensorflow.org/lite/guide/build_cmake_arm?hl=en are not intended to be executed on the Raspberry Pi (at least the last ones).
Let me share, what I'll figured out.
Short answer:
you're trying to run a cross-compile of TensorFlow Lite for an ARM made for x86 platform on an ARM system (your Raspberry Pi). What you're trying to do actually needs to be done on an x86 platform.
(on the top of the tutorial page is a hint: "following instructions have been tested on Ubuntu 16.04.3 64-bit PC (AMD64)" which reveals that the commands have been run on x86)
Some details:
The message ‘Syntax error: "(" unexpected’ probably comes from a shell. Why is a shell trying to execute your binary? Because the kernel tried and gave up. Why did the kernel fail to run the program? Because the executable is not in a supported format -> meant to be run on x86 but was executed on ARM.
https://unix.stackexchange.com/questions/336436/syntax-error-unexpected-when-execute-a-compiled-c-program
With older TensorFlow versions it was possible to compile TF lite on the Raspberry Pi itself via the
./tensorflow-2.4.1/tensorflow/lite/tools/make/download_dependencies.sh /and build_aarch64_lib.sh scripts.
However, this scripts got removed in version 2.8 (or even with an earlier version before). See note in the Readme of the Git: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/tools/make/README.md
Using Python for inference
Unfortunately I have no real solution how to compile / built TensorFlow Lite on the Raspberry itself. I personally ended up using Python (only needed inference) and followed this Tutorial:
https://qengineering.eu/install-tensorflow-2.7-on-raspberry-64-os.html
I have been using gcc version 5.3.0. It says that it comes with openmp support. But every time when I compile a program using either gcc [by terminal] or via xCode 7, I get same error, "file omp.h not found". I have searched too much on this issue and tried almost everything I found.
First I tried to locate omp.h on my mac. I found some files; then in header file, I used that specific location of omp.h but no help [it gave me linker error].
I installed gcc version 6.0 (pre-release) but no help. I tried changing C_INCLUDE_PATH [which is now, and previously set to none] but that didn't helped me as well.
I reinstalled clang-omp but no help.
I am using llvm compiler version 7.0. Although i have installed clang-omp, there is no omp.h in my /usr/include/*
I changed the compiler and now I am able to run it. [It was issue of clang, which I couldn't solve].
I am a student and Intel is giving Intel Parallel Studio 1 year licence for free to students.
So I downloaded, and installed it.
In xCode, under build settings, I set my compiler to 'Intel C/C++ compiler' and in parallalization, I turned it to 'yes'. That was it. Then it compiled successfully. But, note that you won't be using header file 'omp.h' anymore.
By the way, I am still looking for answers, just to know what I was doing wrong.
You can install 'clang-omp' or 'gcc' (corresponds to GCC 5.3 right now) packages via Homebrew, both of which support OpenMP.
The built in GCC is based upon GCC 4.2.1 abs uses LLVM back end via Dragonegg, which is why it doesn't support OpenMP.
As noted already, Intel compilers support OpenMP on Mac.
I don't use Xcode editor so I don't know how to use any of these from there, but all will work from terminal just as they do on Linux.
the compiler on the mac is clang (based on llvm 3.5) which does not support openmp.
you can try install llvm/clang/openmp from source or using prebuild binaries, but I must admit it does not work as advertised for me…
edit unless you use the -fopenmp=libomp flag.
I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.