Assume that you have a static library built with gcc by another person and you want to find out the version number of gcc that was used for compiling. Is there an easy way to extract this information from the library file?
I already tried out readelf, but all the switches I've used so far did not lead to a gcc version number.
This gets recorded in DW_AT_producer attribute in DWARF debug info. So if you have debug info, try this:
objdump -Wi yourlibrary.a|grep "DW_AT_producer"
I didn't see any official documentation for this attribute, so you might have to check...
Thanks to #dbrank0 I could retrieve the gcc version information from the static library. The solution that helped is provided here: https://stackoverflow.com/a/9673793/3868995
While readelf -wi <library> only lists the included files of the library, strings -a <library> |grep "GCC: (" made the job in my case. Thanks!
Related
While compiling most of the opensource libraries, make command generates .la file, which will have library_names and current=11 age=9 revision=0 version information.
I understand that version information current=11 age=9 revision=0 is generated from the flag version-info in Makefile.am. By just knowing the version information, how does make generate library names?
Example : For libcrack.so
dlname='libcrack.so.2'
# Names of this library.
library_names='libcrack.so.2.9.0 libcrack.so.2 libcrack.so'
# Version information for libcrack.
current=11
age=9
revision=0
version info is specified in Makefile.am as follows
libcrack_la_LDFLAGS = -version-info 11:0:9
Now the question is: How does make generate libcrack.so.2.9.0 with the number 2.9.0 by just taking version-info?
Usually libtool library version system uses the following format
soname.so.<current-age>.<age>.<revision>
That is why in example quoted in the question, libcrack.so.(11-9).9.0 = libcrack.2.9.0.
More detailed information can be found at library versioning
I installed some encryption software called libntru.
The header files are installed in /usr/include/libntru and the file I would like to include from this directory is ntru.h. The compiled library is installed to /usr/lib/libntru.so.
In my makefile, I use gcc's -L and -l flags to link to the library as such -L/usr/lib -lntru, however in my project, I get a compiler error at the line #include <ntru.h>.
How can I link to this library? Thanks in advance for any help.
Check on the instructions with the software; there's at least a chance you're supposed to write one of:
#include <libntru/ntru.h>
#include "libntru/ntru.h"
If that's the case, you won't need to specify anything on the command line to find the headers (no -I option). If you're supposed to write just:
#include <ntru.h>
#include "ntru.h"
Then you need to add -I/usr/include/libntru to the command line.
Note that you probably don't need -L/usr/lib on the command line; the compiler will normally look there anyway, but you will need the -lntru option to specify the library itself, of course.
How can I know the libstdc++ shipped with each gcc version? Is there an an easy way to get this info without the need to install the gcc?
You look in the manual, specifically at http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html which shows the library version numbers for each GCC release.
You can just check the GCC source code, for example the libstdc++/ChangeLog file that comes with it. It shouldn't be too hard to script that.
At first sight, libstdc++ isn't getting real version numbers anymore, they just use the source code repository revision id in the ChangeLog files.
I've just compiled GCC 4.7 to work with stdatomic.h, but I can't seem to -I it. stdatomic.h seems to live in /usr/include/c++/4.4.3, but then the linker tells me it needs a bunch of other files in dirs nearby. If I -I all of them, I still get the error undefined reference to atomic_flag_clear_explicit. Any ideas how I'm supposed to link this right?
First, if you are compiling with GCC 4.7 you should not be including or linking anything from a directory from GCC 4.4.
Second, -I only affects the search path for header files. "undefined reference" is a linker error and usually means it hasn't found the right library. You change the library search path with -L. The linker didn't say it didn't find a library with the right name, it says it didn't find a symbol, so clearly the library it did find didn't have that symbol. I'd suggest you have a versioning problem, perhaps caused by a installation problem.
The <stdatomic.h> header in GCC 4.4 and 4.5 was from an early draft of C++0x atomics, but is not part of the final standard, so it was removed from libstdc++.
The C++ compiler supports C++11 atomics via the C++11 <atomic> header, so you should use that header in C++ code.
When the C compiler supports C11 atomics, the <stdatomic.h> header will be provided again.
Using this command solved the problem for me:
$ scl enable devtoolset-7 bash
I got the same error as you when entering sudo make altinstall for installing Python 3.8.5 on CentOS 7.
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.