I have several versions of a project checkout out and compiled. If I spot an error, I compare the versions to narrow the problem down. Sometimes I enable sanitizers like the AddressSanitizer. If I re-use an executable, I don't remember whether it was compiled with the sanitizers or not. If the executable works fine, I am not sure whether the bug is not there or whether I did not include the sanitizer in this build. So I have to reconfigure and rebuild to make sure I have the sanitizer included.
Is there a way to check whether an executable has been compiled with a sanitizer?
Address sanitizer can also be compiled statically with the -static-libasan option in GCC. Statically compiling address sanitizer is the default mode in Clang.
If you compile address sanitizer statically then it is obviously not possible to use ldd to verify if your binary is sanitized or not. In this case I use nm and check if there are sanitizer symbols in the binary:
nm -an <executable> | grep asan
You need to use __has_feature(address_sanitizer), see http://clang.llvm.org/docs/AddressSanitizer.html (same for other sanitizers).
From man ldd:
ldd prints the shared libraries required by each program or shared library specified on the command line.
As long as address sanitizer requires to link with libasan.so library (actual implementation of sanitizer) you can assume:
If ldd won't print shared lib libasan.so it definitely means that address sanitizer is turned off.
If ldd will print shared lib libasan.so it means that your linker flags includes -lasan, otherwise you`ll get unresolved symbol error during linking. Highly likely that address sanitizer is enabled, unless you have a bug in building system.
Third option if you have bug in your building system. ldd will print libasan.so but address sanitizer will be turned off if you passed to linker -lasan , but didn't pass -fsanitize=address. It means that you linked your executable with address sanitizer but didn't include checks into your executable.
Or you can do objdump -p to see if libasan.so is needed in dymanic sections: NEEDED libasan.so.0. objdump could give the same(and more) information as ldd.
Related
I'm trying to cross compile GNU grep for Windows from Fedora, using their mingw64 cross compilers. The process is really easy, with one exception. By default, it appears that mingw64 doesn't expand wildcards on the command line, so that grep FOO * gives "Invalid argument: *" rather than searching all files in the current directory.
After a bit of research, I found that there is an external symbol, _dowildcard in the mingw64 CRT, that will trigger wildcard expansion if set to -1. But I've found no useful documentation on how to set this (maybe because it's considered obvious ;-)).
I could modify the source code to set the variable, but I'd much prefer to not have to modify the source if at all possible. (I want to set up an automated build, and applying code patches just adds complexity that I'd like to avoid). Is there any way to set _dowildcard from the configure or make command line? I seem to remember older versions of mingw having a setargv.obj file that could be linked into your project to enable wildcard expansion - is there anything similar for mingw64?
Answer from #ssbssa above:
There is a file CRT_glob.o file supplied with the mingw packages, in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/CRT_glob.o (or the corresponding location for 32-bit) that you can link with your executable to activate command line globbing.
You have to specify the file by full pathname for the linker to find it.
How can I add the cusparse library from CUDA in a CMakeLists.txt-file, such that the nvcc compiler includes it automatically with -lcusparse? I already added the line
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-lcusparse)
in CMakeLists.txt with no success. It looks like I'm missing something, because Nsight throws the error
undefined reference to 'cusparseDestroyMatDescr'.
Although when I exclude this line where cusparseDestroyMatDescr is called via commenting it, the Nsight project builds with no error, even with these three lines of code included
cusparseStatus_t status;
cusparseHandle_t handle=0;
cusparseMatDescr_t descr=0;
So it looks like it knows what cusparseStatus_t and so on is, but it does not know what cusparseDestroyMatDescr is.
What do I miss?
The correct way in CMake to link a library is using
target_link_libraries( target library ).
If you use FindCUDA to locate the CUDA installation, the variable CUDA_cusparse_LIBRARY will be defined. Thus, all you need to do is
target_link_libraries( target ${CUDA_cusparse_LIBRARY} )
I recommend to use the CMake CUDAToolkit package, which is available with CMake 3.17 and newer:
find_package(CUDAToolkit REQUIRED)
...
target_link_libraries(target CUDA::cusparse)
I'm working with GT.M source code and read this information in mumps.hlp file :
ZCOMpile
The ZCOMPILE command invokes the GT.M compiler from within the GT.M
run-time environment.
Within GT.M itself, ZCOMPILE provides the functionality of the
mumps command, except for mumps -direct.
So...which compiler to be using in "mumps -direct" mode , which file store source code for this compiler ?
I mean that ,when you type :
GTM> SET ^FOO="BAR"
Which compiler responsible for compiling that command
Ryo,
It's compiled in memory. It's not stored in any file.
--Sam
For example how could I get my image to be compiled using:
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux
?
What does core-image-sato has to do with the toolchains (they supply with Yocto)?
I don't understand...
in local.conf, specify the path of your toolchain in your system.
EXTERNAL_TOOLCHAIN = "/home/manjunath/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2014.11-20121123_linux"
In your original toolchain distro add toolchain-external-linaro.inc
More specifically
you get a directory named meta-linaro-toolchain. you may copy complete or
Add .inc to your distribution (sources/poky/meta-yocto/conf/distro/ in my case)
Try now ...
I want to write a program that outputs a list of libraries that I should link to given source code (or object) files (for C or C++ programs).
In *nix, there are useful tools such as sdl-config and llvm-config. But, I want my program to work on Windows, too.
Usage:
get-library-names -l /path/to/lib a.cpp b.cpp c.cpp d.obj
Then, get-library-names would get a list of function names that are invoked from a.cpp, b.cpp, c.cpp, and d.obj. And, it'll search all library files in /path/to/lib directory and list libraries that are needed to link properly.
Is there such tool already written? Is it not trivial to write a such tool?
How do you find what libraries you should link to?
Thanks.
Yeah, you can create a pkg-config file which will allow you to run 'pkg-config --cflags' to get the compiler flags or 'pkg-config --libs' to get the linker libraries.
http://pkg-config.freedesktop.org/wiki/
If you're on Linux, just try looking into /usr/lib/pkgconfig to find some example .pc files that you can use as models. You can still use pkg-config on Windows as well, but it's not something that comes with it.