I am working on Windows 7, using Eclipse DS-5, to cross-compile projects for Altera SoC (FPGA+ARM). The toolchain is supplied by Altera tools, and it looks as follows :
GCC C++ Compiler 4 [arm-linux-gnueabihf]
GCC C Compiler 4 [arm-linux-gnueabihf]
GCC Assembler 4 [arm-linux-gnueabihf]
GCC C Linker 4 [arm-linux-gnueabihf]
GCC C++ Linker 4 [arm-linux-gnueabihf]
GCC Archiver 4 [arm-linux-gnueabihf]
The Altera SoC board is running Angstrom Linux distribution on ARM.
I need to add some libraries (e.g. libcURL) and set the Eclipse project settings, to include the library in compilation.
MY UNDERSTANDING:
Libraries in general contain 2 components. The headers and the library definition files (in binary format). The compiler requires the header files, The linker is then linking the library files.
(If anything above is wrong, please correct me).
MY QUESTIONS:
1) In case the binary files are not supplied for ARM processor, do I need to use Altera tools to compile the library source code on my Windows 7 machine with ARM compiler ?
I believe to use the Altera supplied compiler terminal, to run ./configure, make
2) For such widely used libraries such as libcURL, there are pre-compiled binaries for different platforms. How do I know what the compiled library looks like ? What files are necessary for Eclipse to compile the whole project (please be specific : *.lib, *.a, *.h, ...)
SUMMARY:
I am perplexed by cross-compilation, I am not sure, which compiler is required, and which library files are required.
Most common error I have came across is :
cannot find -lcurl
Does that mean the compiler can see *.h files, but the Linker is not able to locate binary files ?
Finally, I did the following :
I have copied the library source files to my target platform (Altera De_nano_SoC ARM) and compiled the library there (Angstrom Linux, compiler arm-angstrom-linux-gnueabi). This requires setting configuration file in library folder, and running make and make install commands.
Once compiled, I copied the output files (headers *.h and static library files *.a OR shared library files *.so - depending on compilation configuration) to my host machine (Windows 7). Then I have added the files to my Eclipse DS-5 project.
The Eclipse requires the path of .../include folder with header files *.h and the .../lib folder including *.a or *.so files.
Related
I have a prepared a minimal Cmake project containing one cpp file which represent the main and one cpp file which represent the shared library, that prints basically hello world.
https://github.com/courteous/wasmELF.git
The target is to compile this miniaml code with emscripten/clang only and produce
1) one WebAssembly (wasm) binary module version 0x1 (MVP)
2) one ELF 64-bit LSB
without clearing the cmake build directory and rebuilding it again.
Currently i can successfully produce them bought by running the commands
emconfigure cmake ../ -DCMAKE_BUILD_TYPE=WASM
make
and
cmake ../ -DCMAKE_BUILD_TYPE=Linux
make
However the problem is that in order to do that i need to compile the first one with Clang the to remove the build and then to do a second compilation with GCC. I would like Emscripten/Clang to produce them bought instead. I do not want to delete the build directory since the compilation times is taking too long. (Well not in this Project but imagine if the project was much larger)
What i see is that emscripten/clang selects always a target "wasm32-unknown-emscripten"
clang++ -target wasm32-unknown-emscripten
and if i understand that correctly the target should change
I do see that the project is producing LLVM IR bitcode since i have send the flag "flto"
i.e.
file TestSharedClass.cpp.o
TestSharedClass.cpp.o: LLVM IR bitcode
and in the CMakeLists.txt
set(CMAKE_CXX_FLAGS "-flto")
x86_64-unknown-linux-gnu is a supported target by emscripten/Clang
~/Projects/emscripten/emsdk/upstream/bin$ ./llc --version
LLVM (http://llvm.org/):
LLVM version 11.0.0git
Optimized build with assertions.
Default target: x86_64-unknown-linux-gnu
Host CPU: haswell
Registered Targets:
wasm32 - WebAssembly 32-bit
wasm64 - WebAssembly 64-bit
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
In cmake i do have
SET(TARGET x86_64-unknown-linux-gnu)
however when i run
emconfigure cmake ../ -DCMAKE_BUILD_TYPE=Linux
make
i get mainTestFile.js and mainTestFile.wasm instead of ELF 64-bitcode.
what i am doing wrong here. How to tell clang to product once ELF and once wasm from the same code run without having to clear the build directory. This should be possible since clang is producing LLVM IR bitcode. Or do i understand that wrong?
https://github.com/emscripten-core/emscripten/issues/10361
OK that seems to not be possible i.e. the reply from the dev on github states that emcc or emmake can not be used with another target other then wasm32-unknown-emscripten.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I am using Ubuntu 13.04 and installed mingw-w64 using apt-get install mingw-w64. I can compile and link a working 64-bit version of my program with the following command:
x86_64-w64-mingw32-g++ code.cpp -o app.exe
Which generates a 64-bit app.exe file.
What binary or command line flags do I use to generate a 32-bit version of app.exe?
That depends on which variant of toolchain you're currently using. Both DWARF and SEH variants (which come starting from GCC 4.8.0) are only single-target. You can see it yourself by inspecting the directory structure of their distributions, i.e. they contain only the libraries with either 64- or 32-bit addressing, but not both. On the other hand, plain old SJLJ distributions are indeed dual-target, and in order to build 32-bit target, just supply -m32 flag. If that doesn't work, then just build with i686-w64-mingw32-g++.
BONUS
By the way, the three corresponding dynamic-link libraries (DLLs) implementing each GCC exception model are
libgcc_s_dw2-1.dll (DWARF);
libgcc_s_seh-1.dll (SEH);
libgcc_s_sjlj-1.dll (SJLJ).
Hence, to find out what exception model does your current MinGW-w64 distribution exactly provide, you can either
inspect directory and file structure of MinGW-w64 installation in hope to locate one of those DLLs (typically in bin); or
build some real or test C++ code involving exception handling to force linkage with one of those DLLs and then see on which one of those DLLs does the built target depend (for example, can be seen with Dependency Walker on Windows); or
take brute force approach and compile some test code to assembly (instead of machine code) and look for presence of references like ___gxx_personality_v* (DWARF), ___gxx_personality_seh* (SEH), ___gxx_personality_sj* (SJLJ); see Obtaining current GCC exception model.
I am trying to build c file included by ndk under cygwin
In Android.mk, I add -I/usr/include to LOCAL_FLAGS like
LOCAL_FLAGS := -I/usr/include
And I have checked that openssl does under /usr/include
But when I run ndk-build under by project dir, it output
"fatal error: openssl/ssl.h: No such file or directory"
I think I have specified the include directory, but not solve this problem.
Is there any other way can I try?
You seem to have some gaps in your knowledge:
C code compiles to processor's native instruction set. Your desktop/build machine probably has a different architecture from your Android device(thus a different instruction set).
NDK doesn't just compile, it cross-compiles. It means that the NDK runs on the build machine, but the executable it produces cannot run on the build machine(different instruction sets).
All libraries on your desktop are in your desktop's processoer's instruction set. Thus, you cannot link any program build by the NDK using the desktop's libraries. This means:
No includes from '/usr/include/'
No libs from /lib, /usr/lib, /lib64 or /usr/lib64
No Cygwin packages under on Windows
What you need to do is build your own openssl using the NDK and use that to link against when you build your executable.
Please note that the answer is missing a lot of information (at least 3 Bachelor's level Computer Science courses worth of information).
I wanted to write small streaming software using VLC compoents on windows. So i look for : lib and headers file for VLC on windows. Instead of compiling it , to make it faster i looked for ready builds for windows. And i found on: http://nightlies.videolan.org/build/win32/last/
I download it (debug) : Find include file directory and lib. But lib directory contains trange (at least for me) file extensions such as libvlc.la and libvlc.dll.a
What are they? Can i use them in Visual C++?
The .la files are libtool convenience libraries, they're useless and only cause trouble (in this case).
The .a files are (import) libraries for GCC/MinGW, just like .lib for MSVC.
VLC can only be built with GCC, because MSVC lacks the proper C99 support. So all debug info will be generated by and for a GNU toolchain (GCC/Binutils/GDB). If you want to use the proper DLL in Visual Studio, you should be able to create an import library from the included .def file and the dll.