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
Related
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 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.
Ok,this is something am having problems with. I recently installed Matlab R2013a on a x86_64 Linux system running RHEL 5, attached to a Tesla S2050. I have never used the GPU functionality in Matlab itself (but have tried some of it using Jacket that lets one
program GPUs in Matlab).
The Tesla is working fine with all the drivers ,CUDA installed (Jacket v1.8.2 is running fine without complaints).
** Driver Version: 270.41.34 (the last version from 2011, supporting S2050) **
CUDA: v5.0.35
nvcc -V : Cuda compilation tools, release 5.0, V0.2.1221
But the Matlab r2013a complains:
gpuDevice errors:
Caused by:
The CUDA driver was found, but it is too old. The CUDA driver on your system supports CUDA version 4. The required CUDA version is 5 or greater.
Now, I understand the error that Matlab has problems with the Driver version. But, I have installed the latest CUDA toolkit and the latest driver that nVidia has to offer for the Tesla S2050 that I have.
Is there a later driver version available for this Tesla (i downloaded the latest driver & when trying to install, it simply complains that I don't have the compatible nVidia hardware).
How do I tell Matlab to consider the relevant CUDA ? (where to set PATH, CUDA_PATH etc., if any ? )
Are there any other checks i need to perform the evaluate the working of the attached Tesla ?
Thanks in advance for help.
You cannot use CUDA 5.0 with driver 270.41.34. CUDA 5 requires 304.54 or newer. This is not a MATLAB issue.
Newer drivers that support CUDA 5 will also support Tesla S2050.
For example this recent 319.17 driver lists Tesla S2050 on the supported products tab. Or use the 304.54 that comes with cuda 5.0.
this is the session of building exe file in matlab 7.1.
I think I have a problem with the compiler.
mbuild -setup
Please choose your compiler for building standalone MATLAB
applications: Would you like mbuild to locate installed compilers
[y]/n? y
Select a compiler:
[1] Microsoft Visual C++ 2008 Express in C:\Program Files (x86)\Microsoft Visual Studio 9.0
[0] None
Compiler: 1
Please verify your choices:
Compiler: Microsoft Visual C++ 2008 Express
Location: C:\Program Files (x86)\Microsoft Visual Studio 9.0
Are these correct [y]/n? y
*****************************************************************************
Error: Could not find the 64-bit compiler. This may indicate that the
"X64 Compilers and Tools" or the Microsoft Windows Software
Development Kit (SDK) is not installed. To build 64-bit binaries,
Microsoft Visual C++ 2008 Express Edition requires that these two
packages be properly installed.
*****************************************************************************
Trying to update options file: C:\Users\****\AppData\Roaming\MathWorks\MATLAB\R2010a\compopts.bat
From template: C:\PROGRA~1\MATLAB\R2010a\bin\win64\mbuildopts\msvc90freecompp.bat
Done . . .
>> mcc -m mainmain.m -o mainmain
Could not find the compiler "cl" on the DOS path.
Use mbuild -setup to configure your environment properly.
C:\PROGRA~1\MATLAB\R2010A\BIN\MEX.PL: Error: Unable to locate compiler.
Error: An error occurred while shelling out to mbuild (error code = 2).
Unable to build executable (specify the -v option for more information).
??? Error using ==> mcc
Error executing mcc, return status = 1 (0x1).
if the problem is with the compiler, how can I install another compiler?
I have windows 7 (64 bits) and I want that the exe file will work on windows operating system.
This is probably the result of one of two issues.
1) You don't have the Windows SDK installed (as indicated in the error message). According to this MathWorks page regarding supported compilers
Both Microsoft Visual Studio 2008 and Windows Software Development Kit (SDK) 6.1 must be installed. When installing Microsoft Visual Studio, you must choose "X64 Compilers and Tools" when installing Microsoft Visual Studio; this is not selected by default.
Now, keep in mind, this reference is for the most recent release of MATLAB, but I'm betting that this information is still relevant to your issue.
You can download the SDK here.
2) It's also possible that the compiler that you're using simply isn't supported for your release of MATLAB. See here for info on supported compilers for MATLAB 7.1.
Here is the tool stack: Installed on Windows 7 (x64) is Eclipse (Juno x64) with CDT and the SConsolidator plugin. Underneath is the TDM-GCC (x64) bundle installed with 64-bit support.
If I build a 64-bit application and debug it using Eclipse (which uses gdb bundled with GCC), it builds without error and debugs fine.
When I build a 32-bit application and try to debug it with Eclipse, it builds fine but gdb fails:
gdb: unknown target exception 0x4000001f...
Debugging it with the same gdb via command line works fine.
Any ideas on how to work around this?
FYI: Here are some warnings leading up to the gdb exception:
warning: `C:\Windows\system32\ntdll.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: Could not load shared library symbols for ntdll32.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
I had a similar problem in a different scenario but i think the solution should be applicable here too.
I was gdb.exe downloaded from http://www.equation.com/servlet/equation.cmd?fa=gdb to debug a C++ program.
I first tried the 64-bit because my pc is 64-bit but I got the same error as Paul got above. Then I tried 32-bit gdb.exe and it worked.
I also followed the links that were given by Paul and there was also bundle available for 32-bit. So I assume the bundles depend on the type of application rather than the configuration of the platform. But, I doubt 64-bit bundle will work on 32-bit architecture. I haven't tried that and can't say for sure.
I suggest install the bundles that support 32-bit to debug a 32-bit application.