I'm reading Intel VTune documentation about OpenMP and I found this:
To analyze an OpenMP application compiled with GCC*, make sure the GCC
OpenMP library (libgomp.so) contains symbol information. To verify,
search for libgomp.so and use the nm command to check symbols, for
example: $ nm libgomp.so.1.0.0 If the library does not contain any
symbols, either install/compile a new library with symbols or Debug
Information for Application Binaries for the library.
nm /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
nm: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0: no symbols
But now I don't know install/compile a new library with symbols or Debug Information for Application Binaries for the library.
Related
I have followed the Installation and Quickstart instructions, and am writing a CMake project to use Drake.
I'm looking at a unittest that builds in Drake, run it, and it builds, runs, and passes. However, when I try to use some of that functionality in my CMake project, I get a linker error, such as:
undefined reference to `RigidBodyTree<double>::get_position_name(int) const'
If I look at symbols in the Drake shared library (e.g. nm -C or objdump -TC with grep), I see the signature RigidBodyTree<double>::get_position_name[abi:cxx11](int). However, if I look in the produced object code (which causes the linking to fail), I see RigidBodyTree<double>::get_position_name(int).
(Note: This post is a means to migrate from http://drake.mit.edu/faq.html to StackOverflow for user-based questions.)
This is most likely due to an incompatibilty between the compiler used to produce Drake (e.g. clang) and the compiler that CMake has selected (e.g. gcc-4.9). Specifically, gcc-4.9 or before does not tend to handle the DualABI well when linking against clang-compiled code (ref). You may be able to use other functions, because only functions that return an ABI-dependent class (e.g. std::string) are tagged with the ABI that they are using (since they cannot be distinguished in the function signature).
The fix is to change the compiler CMake is using. One way to do this is to set the CC and CXX environment variables to use a supported compiler. For a list of supported compilers, see Supported Configurations. If you are using pre-compiled binaries, please refer to Binary Packages for the compilers used.
WARNING: Do NOT change the compiler using update-alternatives in Ubuntu, as this may affect your DKMS module compatibility with the kernel (among other things) (ref).
I am using nvcodec sdk (https://developer.nvidia.com/nvidia-video-codec-sdk) and use its linux static library in my project.
I added the compile option in gcc with
gcc myprogram.c NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so
However, when running the program,
./bin/a.out: symbol lookup error: ./bin/a.out: undefined symbol: cuvidGetDecodeStatus
I found that the symbol cuvidGetDecodeStatus is actually in NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so.
And by
nm a.out
the symbol is included in the program.
so I tried
ldd a.out
I found it's linked to nvidia driver with same name.
libnvcuvid.so.1 => /usr/lib/nvidia-384/libnvcuvid.so.1
I can't modify the LD_LIBRARY_PATH to modify the search order since NvCodec is a static library.
I have no idea why it's linked to the nvidia driver library even I don't add link option (like -lnvcuvid)
And idea?
thank you
as #Robert Crovella said,
this is an issue for an outdated driver. the library in the cuda codec sdk is actually a stub, which points to the cuda driver shared library.
And there is no symbol like cuvidGetDecodeStatus in the nvidia-384 driver library.
after update nvidia-384 to nvidia-396, the problem solved.
I would expect to be able to statically link against a build of libc with debug symbols, then run my program through lldb.
otool -L <my binary>
makes it look like the only dynamically linked library (dll) is:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
Which I would guess is the libc dll is (though nm doesn't list everything I'd expect in libc). Maybe just some kind of stub loader.
In /usr/lib/ it seems that Apple does not supply a debug build of libSystem.
How do you debug libc on OSX (10.11.3)?
Possible duplicate of:
On Mac OS X, how can you get a debug build of System/LibC for source level debugging?
I'm having a hard time following your question, but there are certain points to be made which I think will cover what you're asking:
otool -L will show all dylibs that you are linking against.
/usr/lib/libSystem.B.dylib is an umbrella library that re-exports multiple dylibs, including libc (/usr/lib/system/libsystem_c.dylib). If you want to see what symbols are part of the system's C runtime, you will want to use nm on that dylib, not libSystem.
If you are statically linking in your own libc, then it won't show up in 'otool -L' because it's a static library and is thus part of your executable.
If you staticy linked your own libc into your executable, then using nm on your binary will possibly not show all the symbols you are expecting because the linker will optimize away dead code that is not needed by your executable. You can ensure that everything is added by using the -force_load option to ld. Check out the ld man page for more details on that.
From where can I download readelf and objdump binaries for OS X? I'm trying to get the list of exported functions from an NDK .so library and neither nm nor otool worked for me. I've read that the library might be in elf format and that readelf or objdump might work.
I was able to find the source code for those utilities but I would like the binaries. Surely they've been compiled by someone already.
There was a lot of information in this SO article: How do I list the symbols in a .so file It is there that readelf and objdump are recommended when nm did not work for me.
These tools are available as part of the NDK. You'll find them in the toolchains subdirectory within the NDK, e.g. android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump. There's also a version of the nm utility there which will understand your ELF .so files, arm-linux-androideabi-nm in the same path as above.
I have debug versions of libstdc++ and libc, among others, and would like to link against them. They live in /usr/lib/debug as opposed to /usr/lib. Any ideas?
I believe the accepted answer is misleading in that the libraries in /usr/lib/debug is not a debug compiled (-g -O0 ...) version of libraries in /lib,/usr/lib but simply debug symbols stripped from the corresponding library in /lib,/usr/lib. See the explanation the accepted answers to How to use debug version of libc and for How to link against debug versions of libc and libstdc++ in GCC? more details.
Quotes:
The libraries in /usr/lib/debug are not real libraries. Rather, the contain only debug info, but do not contain .text nor .data sections of the real libc.so.6
and
On many Linux installations the debug libraries do not contain real code; they only contain the debug info. The two are separated so that you can choose not to install them if you don't need them and you are short of disk space, but the debug libraries are no good on their own.
Check yourself with:
objdump -h /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so | grep -C1 text
11 .text 001488a3 000000000001f520 000000000001f520 000002b4 2**4
ALLOC, READONLY, CODE
The .text segment is ALLOC but without CONTENTS. Compare with the corresponding library in /lib/x86_64-linux-gnu/libc-2.19.so:
$ objdump -h /lib/x86_64-linux-gnu/libc-2.19.so | grep -C1 text
11 .text 001488a3 000000000001f520 000000000001f520 0001f520 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
Assuming Linux,
Static libraries: add a -L/usr/lib/debug to your linker command line. gcc/ld will look there before default system directories. Use ldd command to verify that correct library versions were linked against (shared libraries only).
Shared libraries: set LD_LIBRARY_PATH=usr/lib/debug, and your application will pick up libraries from there even without step 1, as long as there is a version of a library, which is very likely if you are installing with distribution's package manager.
It's a good idea to do both, though, as some libraries may be only in static form.
Use linker flags. ld/gcc -L<LIBRARY_PATH> is important for link time only, regardless shared or static, you cannot link against library, if linker can't find it.
For shared libraries environment variable LD_LIBRARY_PATH is important for start up time. Dynamic libraries loader ld.so and ld-linux.so will look up there when you start your application.