I am trying to debug a potential memory corruption in my application that is using DPDK 21.11 using https://doc.dpdk.org/guides/prog_guide/asan.html
I have installed libasan as required. However, I am unable to compile DPDK 21.11 when I add -Db_sanitize=address to the meson option.
20:44:42 [root]: yum install libasan
Package libasan-8.5.0-10.el8.x86_64 is already installed.
meson -Db_sanitize=address -Dprefix=/ build
The Meson build system
Version: 0.61.2
Source dir: /root/repo/gNB_CU/ngp/thirdparty/dpdk/dpdk-21.11
Build dir: /root/repo/gNB_CU/ngp/thirdparty/dpdk/dpdk-21.11/build
Build type: native build
Program cat found: YES (/usr/bin/cat)
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Project name: DPDK
Project version: 21.11.0
C compiler for the host machine: cc (gcc 10.3.1 "cc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)")
C linker for the host machine: cc ld.bfd 2.35-8
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program pkg-config found: YES (/usr/bin/pkg-config)
Program check-symbols.sh found: YES (/root/repo/gNB_CU/ngp/thirdparty/dpdk/dpdk-21.11/buildtools/check-symbols.sh)
Program options-ibverbs-static.sh found: YES (/root/repo/gNB_CU/ngp/thirdparty/dpdk/dpdk-21.11/buildtools/options-ibverbs-static.sh)
Program objdump found: YES (/opt/rh/gcc-toolset-10/root/usr/bin/objdump)
Program python3 found: YES (/usr/bin/python3.6)
WARNING: Python files installed by Meson might not be found by python interpreter.
This warning can be avoided by setting "python.platlibdir" option.
WARNING: Python files installed by Meson might not be found by python interpreter.
This warning can be avoided by setting "python.purelibdir" option.
Program cat found: YES (/usr/bin/cat)
Checking for size of "void *" : 8
Checking for size of "void *" : 8
Library m found: YES
Library numa found: YES
Has header "numaif.h" : YES
Library libfdt found: NO
Library libexecinfo found: NO
Found pkg-config: /usr/bin/pkg-config (1.4.2)
Run-time dependency libarchive found: NO (tried pkgconfig)
Run-time dependency libbsd found: NO (tried pkgconfig)
Run-time dependency jansson found: NO (tried pkgconfig)
Run-time dependency libpcap found: YES 1.9.1
Has header "pcap.h" with dependency libpcap: YES
Compiler for C supports arguments -Wextra: YES
config/meson.build:290: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Compiler for C supports arguments -Wcast-qual: YES
Compiler for C supports arguments -Wdeprecated: YES
Compiler for C supports arguments -Wformat: YES
Compiler for C supports arguments -Wformat-nonliteral: YES
Compiler for C supports arguments -Wformat-security: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wsign-compare: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wwrite-strings: YES
Compiler for C supports arguments -Wno-address-of-packed-member: YES
Compiler for C supports arguments -Wno-packed-not-aligned: YES
Compiler for C supports arguments -Wno-missing-field-initializers: YES
Compiler for C supports arguments -Wno-zero-length-bounds: YES
Compiler for C supports arguments -mno-avx512f: YES
config/x86/meson.build:10: WARNING: Binutils error with AVX512 assembly, disabling AVX512 support
Compiler for C supports arguments -mavx512f: YES
Checking if "AVX512 checking" compiles: YES
Fetching value of define "__SSE4_2__" : 1
Fetching value of define "__AES__" : 1
Fetching value of define "__AVX__" : 1
Fetching value of define "__AVX2__" :
Fetching value of define "__AVX512BW__" :
Fetching value of define "__AVX512CD__" :
Fetching value of define "__AVX512DQ__" :
Fetching value of define "__AVX512F__" :
Fetching value of define "__AVX512VL__" :
Fetching value of define "__PCLMUL__" : 1
Fetching value of define "__RDRND__" :
Fetching value of define "__RDSEED__" :
Fetching value of define "__VPCLMULQDQ__" :
config/meson.build:427:8: ERROR: C shared or static library 'asan' not found
How do I link the asan library ?
Related
On a CI machine I have cmake echoing back some basic compiler variables at the start. After updating clang from 12 to 13, I am seeing both versions here:
-- CMAKE_C_COMPILER: /usr/local/bin/clang
-- CMAKE_C_COMPILER_ID: Clang
-- CMAKE_C_COMPILER_VERSION: 12.0.0
clang version 13.0.0 (/tmp/llvm-project/clang d7b669b3a30345cfcdb2fde2af6f48aa4b94845d)
-- CMAKE_CXX_COMPILER: /usr/local/bin/clang++
-- CMAKE_CXX_COMPILER_ID: Clang
-- CMAKE_CXX_COMPILER_VERSION: 12.0.0
clang version 13.0.0 (/tmp/llvm-project/clang d7b669b3a30345cfcdb2fde2af6f48aa4b94845d)
Note that "13.0.0" comes from actually running clang --version via these cmake functions:
message(STATUS "CMAKE_C_COMPILER: " ${CMAKE_C_COMPILER} )
message(STATUS "CMAKE_C_COMPILER_ID: ${CMAKE_C_COMPILER_ID}")
message(STATUS "CMAKE_C_COMPILER_VERSION: ${CMAKE_C_COMPILER_VERSION}")
execute_process(COMMAND ${CMAKE_C_COMPILER} ${COMPILER_VERSION_ARG} )
Additional info that might be relevant:
-- CMake version: 3.18.1-g262b901
-- Using ccache.
-- Using sanitizer: address
The issue becomes relevant because some later build steps fail as they are checking the compiler version and thus making the wrong decisions. Is there some local caching that could result in such weird behavior? To my understanding this should not be dependent on caching though?
Update: I tossed the CMAKE_C_COMPILER_VERSION check and used check_c_compiler_flag instead, see my answer below.
CMake found /usr/local/bin/clang, not /tmp/llvm-project/clang. You might want to explicitly set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to ensure that CMake finds the Clang you intend it should be used.
Clang 13 introduced two new checks that broke some external libs. Instead of checking the clang version doing a feature check is better anyway:
# clang 13 introduced stricter checks, for now, disable the warning:
include(CheckCCompilerFlag)
check_c_compiler_flag(-Wno-unused-but-set-variable HAS_UNUSED_BUT_SET_VARIABLE)
if (HAS_UNUSED_BUT_SET_VARIABLE)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-unused-but-set-variable")
endif()
The same can be applied to -Wno-unused-but-set-parameter, of course. Also use CheckCxxCompilerFlag/check_cxx_compiler_flag instead for C++.
I have written and built an R package that depends on Rcpp and requires the C++0x standard (for using the tgamma function in C++). I have tested the package on various desktop computers and operating systems, and it always seems to install and work fine. However, I would also like to use the package on an HPC server. When I try to install the package there in my local R library tree using R CMD INSTALL test (where test is the name of the package), I get the following error message from the compiler:
/usr/include/c++/4.4.7/c++0x_warning.h(31): catastrophic error: #error directive: This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
It basically tells me that I should enable C++0x support when the compiler is called (as in this post). Yet, I thought adding the statement CXX_STD = CXX11 to the src/Makevars file in the R package would actually tell the compiler that this version needs to be used. And indeed that seems to be the case on various desktop computers I have tried. So my question is: how can I tell the compiler on the server that this C++ version should be used for compilation? Alternatively, how else can I install the package?
On the server, I load the module for R by entering module load math/R on the terminal before trying to install the package, and it reports back that the following modules were loaded:
Loading module dependency 'compiler/intel/13.1'.
Loading module dependency 'numlib/mkl/11.0.5'.
Edit 1: The server is a German university cluster called bwUniCluster. It is based on KITE 2.0/RHEL6.5/Lustre 2.5.2. As far as I can tell from the module message reported above, it seems to be the Intel C++ Compiler XE (ICPC) version 13.1.3. But actually I have no clue about compilers, so if you need to know anything more specific, please let me know.
Edit 2 It's also possible to execute module load compiler/gnu/4.9 on the terminal before I try to install the package. This results in the following error message (similar as the one above), which leads me to think that this is not a version problem:
/pfs/data1/software_uc1/bwhpc/common/compiler/gnu/4.9.2/bin/../include/c++/4.9.2/bits/c++0x_warning.h(32): catastrophic error: #error directive: This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
Edit 3: One of the comments suggests that both the R package and R itself need to be compiled using the same compiler version. Is this correct? R was built using g++ 4.4.7 on this machine. Does this mean that the only feasible solution is to convince the sys admin to recompile R with the other 4.9.2 compiler and provide it as a new module? I find this hard to believe, given the following sentence in the "Writing R Extensions" manual:
On these platforms, it is necessary to select a different compiler for C++11, via personal or site Makevars files.
The solution was indeed to recompile R on the server with a newer compiler, in this case Intel 14 (as discussed in Edit 3 in the original post). The sys admin was so kind to set up a new module for this R version.
I'm trying to build boost on windows 8.1 with Visual Studio 2013 on 64bit system.
b2 toolset="msvc" address-model=64 -s ZLIB_SOURCE=C:\H\M\zlib --build-type=complete stage
Here is full output:
Performing configuration checks
- symlinks supported : no
- junctions supported : yes
- hardlinks supported : yes
- arm : no
- mips1 : no
- power : no
- sparc : no
- x86 : yes
- has_icu builds : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
- iconv (libc) : no
- iconv (separate) : no
- icu : no
- icu (lib64) : no
- message-compiler : yes
- compiler-supports-ssse3 : yes
- compiler-supports-avx2 : yes
- gcc visibility : no
- long double support : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
error: Name clash for '<pstage\lib>boost_system-vc120-mt-1_58.dll'
error:
error: Tried to build the target twice, with property sets having
error: these incompabile properties:
error:
error: - <warnings>all
error: - <architecture>x86 <warnings>on
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.
What does it mean and how to resolve it?
Thanks
builds if I add --without-context --without-coroutine to b2 options
From the Boost 1.58 beta release notes:
Important Note
There is a bug with the build scripts; you have to specify the
address-mode and architecture to b2. I used:
./b2 address-model=64 architecture=x86
to test this.
Adding these flags to the b2 command solves the problem without having to exclude the context and coroutine libraries (handy if, say, you actually use these libraries, like I do!).
Naturally, if you're building 32-bit libraries, you want to add address-model=32 instead.
Did you get boost from git repository?
If so, I think the latest version available in git is broken. Today I tried to compile it too and if you would solve errors you mentioned, you will get another errors because of incomplete files in destination directories (boost ptr_container library isn't installed after compilation from source)
The solution was download latest boost version from their site (http://sourceforge.net/projects/boost/files/boost/1.57.0/). After that, compilation and installation works correctly
In my case I was using variant=release,debug command line argument, which was causing name collision.
I've added extra argument --layout=tagged and problem disappeared.
See also https://stackoverflow.com/a/55214183/2338477
Maybe you have two version of g++ available in $PATH. Try running where g++. If you see two g++ then remove one from $PATH. And then start over all the build process again. That worked for me and
I am trying to build the MongoDB client library on Cygwin.
Administrator#dev /cygdrive/e/warez/dev-tools/cpp/mongodb-src-r2.4.8
$ scons mongoclient
scons: Reading SConscript files ...
scons version: 2.3.0
python version: 2 7 5 'final' 0
No special config for [cygwin] which probably means it won't work
Checking whether the C++ compiler works(cached) yes
Checking for C header file unistd.h... (cached) yes
Checking whether clock_gettime is declared... (cached) yes
Checking for C library rt... (cached) yes
Checking for C++ header file execinfo.h... (cached) no
Checking for C library pcap... (cached) no
Checking for C library wpcap... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
scons: *** [build/cygwin/normal/mongo/base/error_codes.h] Source `src/mongo/base/generate_error_codes.py' not found, needed by target `build/cygwin/normal/mongo/base/error_codes.h'.
scons: building terminated because of errors.
Administrator#dev /cygdrive/e/warez/dev-tools/cpp/mongodb-src-r2.4.8
$ ls -l src/mongo/base/generate_error_codes.py
-rwx------+ 1 Administrators None 8736 Oct 31 22:15 src/mongo/base/generate_error_codes.py
There are two questions related to building MongoDB driver:
https://stackoverflow.com/questions/16060068/c-mongodb-driver-in-cygwin
Compiling MongoDB C++ driver on Cygwin
They didn't get the error:
No special config for [cygwin] which probably means it won't work
I've tried both mongodb-src-r2.4.8 and latest code from github (https://github.com/mongodb/mongo), with no luck.
How should I fix the issue? Thanks in advance.
Running scons to build MongoDB under Cygwin bash on Windows is not currently supported. The solution is to use a native Visual Studio Command Prompt.
So this should be quite simple but just want to see if I got it right.
I am trying to find out what version of xlC compiler is installed on AIX box.
I tried xlC -v/xlc --version which is not supported by the compiler.
I tried lslpp -L | grep xlC
I get following output but it confuses me (i am releatively new to UNIX world)
xlC.adt.include 8.0.0.0 C F C Set ++ Application
xlC.aix50.rte 8.0.0.0 C F C Set ++ Runtime for AIX 5.0
xlC.cpp 6.0.0.0 C F C for AIX Preprocessor
xlC.msg.en_US.cpp 6.0.0.0 C F C for AIX Preprocessor
xlC.msg.en_US.rte 8.0.0.0 C F C Set ++ Runtime
xlC.rte 8.0.0.0 C F C Set ++ Runtime
This is list on installed packages on box but whats the significance of listing .cpp file.
And which version is on my box?
6.0 or 8.0
Thanks
Try xlC -qversion
Try lslpp -l | grep -i vacpp and check for lines about the C/C++ Compiler:
vacpp.cmp.core 9.0.0.11 APPLIED IBM XL C/C++ Compiler
vacpp.cmp.core 9.0.0.0 COMMITTED IBM XL C/C++ Compiler
This means I have 9.0 installed with a subsequent PTF added.
My corresponding xlc version information looks like this:
% xlc -qversion=verbose
IBM XL C/C++ Enterprise Edition for AIX, V9.0
Version: 09.00.0000.0011
Driver Version: 09.00(C/C++) Level: 090810
C Front End Version: 09.00(C/C++) Level: 090730
C++ Front End Version: 09.00(C/C++) Level: 090730
High-Level Optimizer Version: 09.00(C/C++) and 11.01(Fortran) Level: 090812
Low-Level Optimizer Version: 09.00(C/C++) and 11.01(Fortran) Level: 090902
Also the xlc/rte entries you found are for the C/C++ Runtime, which will depend on the OS version and are not as closely linked to the compiler version. This source of confusion is also mentioned in the link below.
See http://www-01.ibm.com/support/docview.wss?uid=swg21652272
cc –qversion or xlc -qversion or xlC –qversion