I am migrating a Xilinx Zynq board from from the CodeSourcery armel (gnueabi) toolchain (from Vivado 2015.2) to a Linaro armhf, so we could instal Debian/Ubuntu armhf (gnueabihf).
While attempting to dlopen() and dlsym() a shared library, we get the next error from dlerror():
/.../controller.so: undefined symbol: _ZTVN10__cxxabiv119__pointer_type_infoE
The issue is present if the Linaro toolchain is used while software compiled with the CodeSourcery toolchain works properly.
I checked both libraries for the reported symbol and it is present in both:
$ grep -r cxxabiv119__pointer_type_info .
./controller.so.armel.simbols:U _ZTVN10__cxxabiv119__pointer_type_infoE
./controller.so.armhf.simbols:U _ZTVN10__cxxabiv119__pointer_type_infoE
It seems that if controller.so contains only C code (no C++ code) it works properry with Linaro. But the difference might be something else than the language used.
Regards,
Iztok Jeras
There was no simple answer to this problem, in the end I switched from cross compiling to a native compiler inside a QEMU emulated ARM environment. This was suggested by various Raspberry PI users. On the other hand every cross compiler solution just unearthed a new set of problems.
Related
We are trying to build ORAN- ODU-Low library (https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/build_prerequisite.html).
We have downloaded and built DPDK ,
#wget http://static.dpdk.org/rel/dpdk-18.08.tar.x
#tar -xf dpdk-18.08.tar.xz
#export RTE_TARGET=x86_64-native-linuxapp-icc
#export RTE_SDK=Intallation_DIR/dpdk-18.08
build DPDK:
#./usertools/dpdk-setup.sh
select [39] x86_64-native-linuxapp-icc
exit [62] Exit Script
'''
DPDK built successfully.
While building fapi library from odu, we see below errors:
In file included from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_dpdk.h:28:0,from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_args.h:23,from /home/user/odu-low/phy/fapi_5g/source/nr5g_fapi.c:32:
/home/user/odu-low/dpdk-18.08/include/dpdk/rte_memcpy.h:797:2: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h:1246:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/x86intrin.h:34,from /home/user/odu-low/dpdk-18.08/include/dpdk/rte_vect.h:29, from /home/user/odu-low/dpdk-18.08/include/dpdk/rte_memcpy.h:17, from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_dpdk.h:28, from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_args.h:23, from /home/user/odu-low/phy/fapi_5g/source/nr5g_fapi.c:32:
\/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h:700:1: note: expected ‘__m128i’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
We are building it on CentOS 7 - 3.10.0-1160.45.1.el7.x86_64 gcc version used: 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
Intel compiler icc was previously available as a part of intel system studio and required a license. The documentation on installing icc you refer seems to on O-RAN docs seems to be written during this period. Intel system studio now has been replaced by Intel oneAPI toolkits
Currently intel compilers(eg icc) are available for free without any license as a part of intel oneAPI HPC toolkit. You could easily download the toolkit for free by visiting the below link, and start using icc without issues.
https://www.intel.com/content/www/us/en/developer/tools/oneapi/hpc-toolkit-download.html
If you still need to download the older versions of icc you could try out by visiting the below link.
https://www.intel.com/content/www/us/en/developer/articles/guide/download-documentation-intel-system-studio-current-previous.html
My PC is running Ubuntu 17.10 and has GTK+ 3.22.
When compiled from this environment the binaries cannot be run under Ubuntu 16.04 since the only GTK+ 3.18 is compatible with Ubuntu 16.04. How do I compile for a lower GTK runtime level?
The other way around should work though.
Compile the binary on the older OS version and it should work fine on the newer one.
The usual solution is to not provide binaries at all, but let the users and the distribution developers / packagers deal with the problem.
Just make sure your app is easy to compile, which means use standard build system tools like mesonbuild and add some build instruction in a README.md file.
It depends what are your real dependencies on the GTK+ API.
Each function has at the end of its documentation a Since: field that tells on which version of GTK+ it first appeared. Both of your target versions are GTK+ 3, so they are ABI-compatible. So you just need to check which symbols are not found when you run your binaries compiled for 3.22 on your 3.18. Every symbol that isn't found has been added after 3.18. Every symbol with Since: > 3.18 can't be used, you need to use the smallest common denominator. Once the symbols > 3.18 are identified, you have 2 choices:
either you do it the 3.18 way, and change your code to use no symbol introduced after 3.18. This means you might have to use deprecated symbols, but they will be there until the next API break (ie. GTK+ 4).
or try to get the latest features from both versions, using something like:
.
#if GTK_CHECK_VERSION(3, 20, 0)
// Do it the GTK+ >= 3.20 way
#else
// Do it the GTK 3.18 way
// (and ensure you have checks in your configure.ac or similar to make
// sure configuration breaks if trying to build with a GTK+ < 3.18)
#endif
I'm trying to build a shared library to use on a raspberry pi (model 3B) using lazarus. After some puzzling I found out that my original library didn't work properly so I switched to a very simple library using this example.
But even this simple library doesn't compile properly to be used. When I try to open the library in another lazarus project it gives me the error:
< libName >: cannot open shared object file: No such file or directory
After some research I found the following diagnostics I could run. The file and ldd command in the compile library:
$file ./libname.so gives:
./libname.so: ELF 32-bit LSB shared object, ARM, EABI5 verion 1 (SYSV), dynamically linked, not stripped
$ldd ./libname.so
not a dynamic executable
I have searched for similar cases and from found that others had this problem when they tried to use libraries compile for a different platform/architecture. I already set the project>project options>compiler options>target platform to OS:= linux and Target CPU family: arm.
The system I am using (using $uname -a):
Linux raspberrypi 4.4.13-V7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux
with distro: Raspbian GNU/linux 8.0 (jessie)
Lazarus version: 1.2.4+dfsg2-1
FPC version: 2.6.4 arm-linux-gtk2
At this point I am not sure what is wrong and why this library isn't working. I can find very little information on this problem (on the aspberry platform and using lazarus) Any suggestions what I could try to make it work, compile it different or do some more diagnostics?
Found the solution. As Marco proposed above: Add initc to the uses part. It seems that if you try to make a library it has to include initc, cmem or LCL to the uses section because the library has to do some memory management for which it needs one of these units.
However this resulted in another error when trying to load the library:
"Undefined symbol: TC_SYSTEM_ISLIBRARY"
This seems to be a raspberry specific problem, compilers on other systems do not give this error. More information can be found HERE.
Eventually solved this by install fpc 3.0.0 compiler on the raspberry pi, compiled it and the library can be loaded properly (but still needs one of the above units).
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I am using Eclipse Juno parallel version. I have installed
cuda plugin. But while building a sample cuda helloworld
program I am getting error -
make all
make: *** No rule to make target `exe_cuda', needed by `all'. Stop.
******Makefile snapshot**************
all: exe_cuda
# Tool invocations
#echo 'No tool found that can build the extension specified with the build
artifact name $#'
# Other Targets
clean:
-$(RM) $(OBJS)$(C_DEPS) exe_cuda
-#echo ' '
Any suggestion......
I agree that the toolchain does not appear to be set up properly for C projects.
My suggestions are:
Create a C++ project instead. That seems to work.
Use Nsight Eclipse Edition instead. It is installed automatically with the linux CUDA 5 package (just type nsight from a terminal window).
You could report the problem to fixstars corporation, the developer of that cuda plugin. It seems they have not updated it since 2011, so I don't know if it's actively maintained. But the help page is here which includes a link for a mailing list you could use.