I remember finding *.a library that doesn't contain any object but instead a list libraries (as a plain text?), something like: -liconv -lm
So that when gcc encounter it, both library will be searched for linking.
Is there such trick? pretty sure it was working that time, but I don't know how to make it now.
Is your linker from binutils? binutils ld supports .a files as implicit linker scripts:
If you specify a linker input file which the linker can not recognize as an object file or an archive file, it will try to read the file as a linker script. If the file can not be parsed as a linker script, the linker will report an error.
A linker script does not have to be complicated, it can be as simple as this (for glibc's libc.so):
/* GNU ld script. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( …/libc.so.6 …/libc_nonshared.a AS_NEEDED ( …/ld-linux-x86-64.so.2 ) )
Or you can just use INPUT to delegate things to ld:
If you use ‘INPUT (-lfile)’, ld will transform the name to libfile.a, as with the command line argument ‘-l’.
Related
I've been playing around with GCC lately and have been experimenting with the linking options. I'm somewhat confused why the link option -l is necessary when statically linking to an archive file. It seems like you can just toss the .a file as if it were an ordinary object file.
For example, take the following make file:
test1 : main.c libfunc.a
gcc main.c -L. -lfunc -o main.out
test2 : main.c libfunc.a
gcc main.c libfunc.a -o main.out
libfunc.a : func1.c func2.c
gcc func1.c -c
gcc func2.c -c
ar cr libfunc.a func1.o func2.o
Make target test1 uses GCC's linking options to link to the archive file. Target test2 instead just includes the archive file direct. Building and running each output seem to result in the same executable.
There are several ways you can tell gcc what file(s) to use. An argument of the form -lname (or the two arguments -l name) says “Search for a library named name”. Per the GCC documentation, this argument is passed to the linker (typically the ld command). The linker looks for a file with a name like libname.extension, where extension is one of the known library files extensions such as .a or .so, and it looks for files with those names in a list of library directories it has. You can add directories to search with the -L switch.
When the linker finds the library, it uses it just as if you had specified the path, so the end result is the same whether you specify the library with -l or with its path.
By using the path, you can specify libraries that are not in the known library directories or that have unusual names.
Note that the linker does not process libraries the same way as object files. When the linker processes an object file, it incorporates everything in the object file into the output file being constructed. When the linker processes a library file, it incorporates only those modules within the library that provide a symbol definition for a symbol referenced by a prior module and not yet resolved. For example, if you write a program that uses sqrt but does not use sin, then, when the linker processes libm.a after reading your object module, it will take the sqrt module from the library but not the sin module.
I have one .a file ( ar command ) which I want to bind it with my .so file during GCC compilation.
How can I do this.
If I run this command :
gcc /usr/local/apr/lib/libapr-1.a ../../ndagentlibc/obj/*.o tideways_xhprof.o tracing.o -shared -o libhello.so
nm libhello.so | grep apr_term
output: U apr_terminate
apr_terminate is not getting its defination
If your .so file needs the .a file, link your .so with the .a file and all of the needed code from the .a archive will be available in the .so file.
Reorder your command and put the .a library at the end...
gcc ../../ndagentlibc/obj/*.o tideways_xhprof.o tracing.o -shared -o libhello.so /usr/local/apr/lib/libapr-1.a
as the ld(1) linker only selects the object modules (*.o) included in a library archive that it knows have unsolved references for at the moment of reading it (as you put it first in your command line, no unsolved references appear by that time, so no library .o component is selected and included at the time of library processing)
In the case of an archive of object modules, the linker tries to do its best, selecting only the ones that appear to be necessary, and putting an archive at first makes the linker to select no files from it to be linked.
note
BTW, the -shared option is used to create a shared object (a .so module) which probably is not what you want. If you want to create a final executable program, don't use -shared. I point at this, because the first time I had to fight with this, I assumed the kind of linking (shared or static) was specified with some option (common mistake, I think) but the kind of linking is actually given, object by object, by the kind of file you feed to the linker, and not with a command line option. Apart of other things, it makes the linker not to comply when some references are missing in the program (it assumes those will be resolved in a later linking)
I've recently begun using a new ELF loader. The loader requires you to link your applications with ld -r.
The problem is that GCC no longer warns me of undefined functions, and then the loader (obviously) fails to find them.
How do I link with ld -r, and get the undefined symbols method.
I am using ld -r for relocation purposes, so a different way to include relocations will also work for me.
In your makefile, define an intermediate target where you link with all the options but the -r one, to a file in the temporary directory (so you're sure not to use it).
If this phase succeeds, then proceed to the real link with the -r option.
With gcc in ubuntu I used this command to compile my source code:
gcc 1.c -L. -lagent -lm -lpthread -o 1
but I got this error:
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
/usr/bin/ld: cannot find -lagent
collect2: ld returned 1 exit status
How can I solve this?
The linker is telling you that the file ./libagent.so exists, but isn't in the appropriate format.
It could be an empty file, or built for 32-bit instead of 64-bit, or it could be a symlink pointing to the wrong version.
Let's look at your command line parameters first.
gcc 1.c -L. -lagent -lm -lpthread -o 1
You call the compiler gcc with the input source code of 1.c and then you specify an additional (link) library path to include the current directory (.) -L.. Then you tell it to link against the agent and pthread libraries, where shared (dynamic) libraries have the default name format of libNAME.so where NAME is replaced with the name. Static libraries have the default file extension .a (from the term archive). Then you specify the output (executable in this case) to be the file 1 (digit one, not the letter 'ell').
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
This is the linker (ld) telling you that the file ./libagent.so (it found presumably in the current directory) is not a valid shared library format as it was expecting. This could be for a different machine architecture (x86-64, ARMle, PowerPC, MIPS) or a incompatible library format (I don't know if library files, .so, have any COFF or ELF or PE dependencies or not). Or simply otherwise empty or corrupted (e.g. interrupted output due to errors compiling / linking).
So you normally want to not include your current directory in your linker's search path, unless you have the copy of the library that you have not yet installed (typically to /usr/lib/ or /usr/local/lib/), such as you wrote the library and wish to link test programs to it before you install it.
Debian and Unbuntu-oriented part of the answer:
Normally you want to install shared library's runtime component (often named something like libagent) and the associated development files (most often at least a header file and hopefully a manpage) in the format libagent-dev. RPM based Linux systems use libagent-devel style naming conventions (from memory). So sudo aptitude install libagent-dev should do the trick if that is the package's name.
i'm new on gcc compiler.
My friend wrote this script (graphic filter) for me but i can't use it because i receive some error.
I have 2 directory and a C file:
-dir- include --> basics.h common.h freeimage.h hqx.h imageIO.h pcxIO.h
-dir- lib --> libfreeimage-3.13.1.so libfreeimage.a libfreeimage.so.3 libhqx.a libhqx.so libhqx.so.1 libhqx.so.1.0.0
scaling.c
i try to compile with this command:
gcc scaling.c -I./include -L./lib -lm -lfreeimage -lhqx -lstdc++ -o filter
But i receive this error:
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/ld:./lib/libhqx.so: file format not recognized; treating as linker script
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/ld:./lib/libhqx.so:1: syntax error
collect2: ld returned 1 exit status
Thanks in advance and sorry for my english.
The linker will treat any file that doesn't look like an object file or library as a linker script containing commands to specify how linking should be done. Things like load addresses, section definitions, etc.
Apparently libhqx.so doesn't look like a shared library on you system. I assume it was built on your friend's system?
To get a clue about what the file is, use the file command. You should get something like:
main% file /lib/libc-2.11.2.so
/lib/libc-2.11.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
If not, you'll have to build or find a library compatible with your system.
I had a similar problem yesterday, and I think your libhqx.so was a symbolic link to libhqx.so.1.0.0 or to libhqx.so.1 in your friend's machine, and when you copied this files, this link had broken. (at least that was the situation in our system, and the problem solved after we remove the .so file, and create the right symbolic link)