I'm trying to build my project with
g++ -O0 -g -fsanitize=address -fno-omit-frame-pointer
but get lots of errors like:
/home/user/libs/opencv/include/opencv2/core/mat.hpp:715: undefined reference to `__asan_report_load8'
How to compile project with AddressSanitize support?
My gcc version is 4.8.4.
You need to add -fsanitize=address to compiler flags (both CFLAGS and CXXFLAGS) and linker flags (LDFLAGS). You've probably added it to your compiler flags only.
Note that using explicit -lasan option has been widely discouraged by ASan developers (e.g. here) as it misses some other important linker flags. The only recommended way to link is to use -fsanitize=address.
As a side note, for more aggressive verification flags check Asan FAQ (look for "more aggressive diagnostics").
Make sure you have libasan installed. For example, in Fedora:
dnf install libasan libasan-static
You need to add the switch -lasan -fsanitize=address to your both your compile and link command line to link the correct library.
Note: the original answer -lasan is outdated and should not be used, as per comments
Related
I have a code running on a PowerPC e500v2 embedded Linux and I want to measure its performance since it is running in an infinite loop. I tried gcc's gprof which was simply by adding -pg option to gcc. When I run the binary on the target device I get this:
./main: /lib/libc.so.6: version GLIBC_2.16 not found (required by ./main)
I am using ELDK 5.6 toolchain with the default CFLAGS and LDFLAGS and these flags: -Wall -lrt -pthread -D_GNU_SOURCE nothing else. Some article suggested defining FORTIFY_SOURCE along with an optimization level but it did not work. I searched for some gcc's feature test macros and tried defining some GLIBC 2.16 specific macros but it did not work.
I faced similar issue with GLIBC 2.17 when I used some structures and functions from <sched.h>, adding _GNU_SOURCE resolved it. Any idea on how to resolve it?
When I run the binary on the target device I get this
Your tool chain targets a version of GLIBC that is newer than what is installed on the target.
This doesn't bite you in non-pg compiles only by accident. An "innocent" change to your source can cause the same problem.
You need to upgrade your target to the version of GLIBC which your toolchain actually builds for.
I am trying to configure the last version of clang (6.0) to use the arm-none-eabi linker instead of the ld.lld but clang is always ignoring everything and keep asking for the ld.lld one. I am trying to build for cortex-m3 (lpx1769 board). How do I force clang to use the linker I want.
-fuse-ld=ld is also not working, so does clang no longer allow the use of any other linker?
So the answer was to use the flag:
-fuse-ld=path/to/linker-to-be-used
Remember that if you passing this flag to clang it will cause a warning that clang will not use this flag (only the linker stage will do). Thus if you compiling with -Werror, the warning will be turned into an error.
Moreover, because you are cross-compiling probably you will need to let the linker know where to find the target-specific libraries needed using the -L option. See this for more info:
https://clang.llvm.org/docs/CrossCompilation.html
I'm trying to build google-glog on Mac OS X 10.8, using following options:
./configure CXX='clang++' CXXFLAGS='-std=c++11 -stdlib=libc++'
Despite that the library gets linked with libstdc++.
Why, and how to fix this?
It's better to put 'dialect' and runtime flags in the compiler variable, since it will use those flags for linking - not just source compilation: CXX="clang++ -std=c++11 -stdlib=libc++"
Save CXXFLAGS for things like -W -Wall -O2 -march=xxx, etc.
Found out that you could use the build variable
LIBS+="-stdlib=libc++"
Seems to me a better place than the compiler variables.
Suppose I have a third party library called somelib.a on a Mac running Mountain Lion with Xcode 4.4 installed. I want to get a dynamic library out of it called somelib.dylib. An appropriate Linux command would be:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.so
where -whole-archive and -no-whole-archive are passed to the linker.
When I do the equivalent for Mac:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.dylib
ld fails with an error:
ld: unknown option: -whole-archive
It seems that the ld on OSX is different from GNU ld. How do I have to modify above command so I will get the desired result?
Thank you in advance!
I found out the solution to my problem:
g++ -fpic -shared -Wl,-force_load somelib.a -o somelib.dylib
The required argument is -force_load:
Which needs to be followed by a single library you wanna ensure gets loaded.
I mean, it needs to be repeated for each library (unlike -noall_load approach, which wrapped them).
For example, -Wl,-force_load libYetAnotherFile.a (where -Wl, part is only required because we don't pass parameter directly to linker).
Note that Old answer (before edit) was using -noall_load instead, but nowadays that causes a linker error (as -noall_load has been removed, was obsolete previously).
Note: A link for the documentation of the OSX ld linker.
http://www.unix.com/man-page/osx/1/ld/
I know it is late to give an answer for this, but I do not have enough reputation to make a comment on #hanslovsky answer.
However, it helps me a lot to have the docs of the options too.
It helps what the options do exactly, and that other options the ld linker also has.
So I just wanted to share with others who finds linking an issue.
UPDATE:
After the comment from #GhostCat I have decided to expand my answer.
The docs for -all_load is:
-all_load
Loads all members of static archive libraries.
So it loads for all static libraries that you note.
If you want something similar to --whole-archive and --no-whole-archive, then you need to use -force_load and -noall_load.
-force_load "path_to_archive"
Loads all members of the specified static archive library. Note: -
all_load forces all members of all archives to be loaded.
This option allows you to target a specific archive.
-noall_load
This is the default. This option is obsolete.
Then you can define which libraries to fully load with -force_load and then later turn it off again with -noall_load.
According to the ld manual, -noall_load is the default and is ignored. (If you use it, you get an error message: ld: warning: option -noall_load is obsolete and being ignored)
Apparently the way to get -all_load to apply to only one library is as follows:
-Wl,-force_load,somelib.a
It is almost common knowledge that one should always compile with -Wall.
What other useful options are you using when compiling with gcc/g++?
You may want -Wextra in addition of -Wall.
When debugging your program, -g is needed by gdb.
and GCC accepts both -g and -O if you really want
At last, recent versions of GCC (i.e. 4.6 or the 4.7 snapshot) gives better warnings than older ones.
You could use -pedantic and restrict yourself to some standard, avoiding GNU extensions.
I love GNU extensions so I don't want to avoid them.
So I use -std=gnu99 for C code, and -std=gnu0x or -std=gnu11 for C++11 code because I like extensions.
And you might consider using or even developing a GCC plugin or a MELT extension for your own specific needs.