I'm working through the current LFS (Linux from scratch) book, section 6.10.
When I attempt to compile the dummy file it fails with
/tools/lib/gcc/i686-pc-linux-gnu/6.2.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
In my investigation I noticed that the spec file that I wrote isn't being used when executing GCC. E.g.
root:~# gcc -v
Reading specs from /tools/lib/gcc/i686-pc-linux-gnu/6.2.0/specs
...
root:~# sed -n '/startfile_prefix_spec/{N;p}' /tools/lib/gcc/i686-pc-linux-gnu/6.2.0/specs
*startfile_prefix_spec:
/usr/lib/
root:~# gcc -dumpspecs | sed -n '/startfile_prefix_spec/{N;p}'
*startfile_prefix_spec:
Is there something wrong with gcc reading the spec file I created?
I fixed the issue with the error. /usr/lib/libgcc_s.so{,.1} were pointing to the wrong location and hence why it could not be found.
Related
I am new to linux programming and learning it from The Linux Programming Interface by Michael Kerrisk.
I have to compile my first program that has dependencies.
Directory structure:
--linux-programs
|--seek_io.c
|--lib
|--tlpi_hdr.h
|--error_functions.h
|--error_functions.c
|--get_num.h
|--ename.c.inc
I want to compile seek_io.c program with dependencies in the lib directory, so that I can see how the program works.
I tried a few things, absolutely clueless on how they work following this stackoverflow answer. I get all sorts of errors as I am an absolute beginner to Linux programming, not to programming, linux OS and C.
Trials:
gcc -I ./lib/ -c ./lib/error_functions.c and then gcc -o seek_io.c ./error_function.o gives error:
/usr/lib/gcc/x86_64-linux-gnu/crt1.o: In function _start:
(.text+0x20): undefined reference to main
collect2: error: ld returned 1 exit status
After this run, on ls I find that my seek_io.c is not listed.
Basically the author of the book says for tlpi_hdr.h file:
This header file includes various other header files used by many of the example programs, defines a Boolean data type, and defines macros for calculating the minimum and maximum of two numeric values. Using this header file allows us to make the example programs a bit shorter.
Link to codes for files mentioned above:
tlpi_hdr.h
error_functions.h
error_functions.c
get_num.h
get_num.c
seek_io.c
The problem is with your second gcc command, where you're using the -o file to specify the output file where to store the resulting executable file, but passing it the name of the C source file seek_io.c instead...
gcc -o seek_io.c ./error_function.o
This means link file error_function.o and store the executable in seek_io.c. This fails because there is no main function, which is needed for a standalone executable, so your C source file is not overwritten by the failing link command.
You can fix this easily by passing the -o option a proper output file name, which in the case (of this link command) should be the name of the executable that you want to create, such as seek_io:
gcc -o seek_io seek_io.c ./error_function.o
(But this will fail without a -I ./lib/, since seek_io.c includes tlpi_hdr.h which is in that directory. If you add it to that command, it should work.)
You can also decide to split the compile and link steps in two separate steps (the command above will both compile seek_io.c into an object file and then link the two object files into an executable) with:
$ gcc -I ./lib/ -c ./lib/error_functions.c
$ gcc -I ./lib/ -c seek_io.c
$ gcc -o seek_io seek_io.o error_function.o
One final nitpick is that for the -I flag to specify the directories where to search for the include files, the more common usage has no space between the flag itself and the directory name, so you'll most commonly see -I./lib or even -Ilib.
$ gcc -Ilib -c ./lib/error_functions.c
$ gcc -Ilib -c seek_io.c
$ gcc -o seek_io seek_io.o error_function.o
Here is the step I'm on. Everything has gone fine up to this point, but after replacing the old linker with the new one and making the changes to the specs file, I get the following error when trying to compile dummy.c
/tools/libexec/gcc/i686-pc-linux-gnu/5.3.0/collect2 -plugin /tools/libexec/gcc/i686-pc-linux-gnu/5.3.0/liblto_plugin.so -plugin-opt=/tools/libexec/gcc/i686-pc-linux-gnu/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cciBczi2.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /tools/lib/gcc/i686-pc-linux-gnu/5.3.0/crtbegin.o -L/tools/lib/gcc/i686-pc-linux-gnu/5.3.0 -L/tools/lib/gcc/i686-pc-linux-gnu/5.3.0/../../../../i686-pc-linux-gnu/lib /tmp/ccxbWIWi.o "" -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tools/lib/gcc/i686-pc-linux-gnu/5.3.0/crtend.o /usr/lib/crtn.o
/tools/lib/gcc/i686-pc-linux-gnu/5.3.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find : No such file or directory
collect2: error: ld returned 1 exit status
After a lot of google searching, I've seen other posts about similar problems at the same stage, but all of those errors refer to specific files that are missing (usually crt*.o files), but this error is different and perplexing in that it doesn't actually list a file it can't find. I've made sure ld and the various links to it exist and do things when you invoke them. I've even cut and pasted the directory into a cd command and it does work (I was originally thrown off by the /../../../../ in the path but it seems to work so okay). What file is missing or not being found by collect2?
The problem was an extra space in the command issued to compile the file.
The correct command is:
cc dummy.c -v -Wl,--verbose &>dummy.log
What I entered was:
cc dummy.c -v -Wl, --verbose &>dummy.log
That very small difference meant four hours of hair pulling. Thank you to everyone who offered help!
I was trying to compile a simple opengl program on msys using g++. To my surprise the linker was complaining on undefined references:
$ g++ -mwindows -lopengl32 glut_md2.cpp
C:\Users\...\cceQtYAy.o:glut_md2.cpp:(.text+0x67a): undefined reference to `glGenTextures#8'
C:\Users\...\cceQtYAy.o:glut_md2.cpp:(.text+0x696): undefined reference to `glBindTexture#8'
....
After googling for a while I found that the problem was in g++ arguments order:
$ g++ glut_md2.cpp -mwindows -lopengl32
--- all ok! ---
The interesting thing is that the correct argument orders in g++ is in the first example. That is:
$ g++ --help
Usage: g++.exe [options] file...
....
Am I missing something? Why moving options after the file argument makes a compilation success? I never had this issue when compiling natively on linux...
I bumped into this problem once or twice, you should put -L and -l at the end of command line. g++ doesn't link, it invokes ld and pass arguments, ld man:
The linker will search an archive only once, at the location where it
is specified on the command line. If the archive defines a symbol
which was undefined in some object which appeared before the archive
on the command line, the linker will include the appropriate file(s)
from the archive. However, an undefined symbol in an object appearing
later on the command line will not cause the linker to search the
archive again.
ld -o /lib/crt0.o hello.o -lc
What is the way to print the search paths that in looked by ld in the order it searches.
You can do this by executing the following command:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
gcc passes a few extra -L paths to the linker, which you can list with the following command:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
The answers suggesting to use ld.so.conf and ldconfig are not correct because they refer to the paths searched by the runtime dynamic linker (i.e. whenever a program is executed), which is not the same as the path searched by ld (i.e. whenever a program is linked).
On Linux, you can use ldconfig, which maintains the ld.so configuration and cache, to print out the directories search by ld.so with
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -v prints out the directories search by the linker (without a leading tab) and the shared libraries found in those directories (with a leading tab); the grep gets the directories. On my machine, this line prints out
/usr/lib64/atlas:
/usr/lib/llvm:
/usr/lib64/llvm:
/usr/lib64/mysql:
/usr/lib64/nvidia:
/usr/lib64/tracker-0.12:
/usr/lib/wine:
/usr/lib64/wine:
/usr/lib64/xulrunner-2:
/lib:
/lib64:
/usr/lib:
/usr/lib64:
/usr/lib64/nvidia/tls: (hwcap: 0x8000000000000000)
/lib/i686: (hwcap: 0x0008000000000000)
/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib/sse2: (hwcap: 0x0000000004000000)
/usr/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib64/sse2: (hwcap: 0x0000000004000000)
The first paths, without hwcap in the line, are either built-in or read from /etc/ld.so.conf.
The linker can then search additional directories under the basic library search path, with names like sse2 corresponding to additional CPU capabilities.
These paths, with hwcap in the line, can contain additional libraries tailored for these CPU capabilities.
One final note: using -p instead of -v above searches the ld.so cache instead.
I'm not sure that there is any option for simply printing the full effective search path.
But: the search path consists of directories specified by -L options on the command line, followed by directories added to the search path by SEARCH_DIR("...") directives in the linker script(s). So you can work it out if you can see both of those, which you can do as follows:
If you're invoking ld directly:
The -L options are whatever you've said they are.
To see the linker script, add the --verbose option. Look for the SEARCH_DIR("...") directives, usually near the top of the output. (Note that these are not necessarily the same for every invocation of ld -- the linker has a number of different built-in default linker scripts, and chooses between them based on various other linker options.)
If you're linking via gcc:
You can pass the -v option to gcc so that it shows you how it invokes the linker. In fact, it normally does not invoke ld directly, but indirectly via a tool called collect2 (which lives in one of its internal directories), which in turn invokes ld. That will show you what -L options are being used.
You can add -Wl,--verbose to the gcc options to make it pass --verbose through to the linker, to see the linker script as described above.
The most compatible command I've found for gcc and clang on Linux (thanks to armando.sano):
$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$'
if you give -m32, it will output the correct library directories.
Examples on my machine:
for g++ -m64:
/usr/x86_64-linux-gnu/lib64
/usr/i686-linux-gnu/lib64
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib64
/lib/x86_64-linux-gnu
/lib64
/usr/lib/x86_64-linux-gnu
/usr/lib64
/usr/local/lib
/lib
/usr/lib
for g++ -m32:
/usr/i686-linux-gnu/lib32
/usr/local/lib32
/lib32
/usr/lib32
/usr/local/lib/i386-linux-gnu
/usr/local/lib
/lib/i386-linux-gnu
/lib
/usr/lib/i386-linux-gnu
/usr/lib
The question is tagged Linux, but maybe this works as well under Linux?
gcc -Xlinker -v
Under Mac OS X, this prints:
#(#)PROGRAM:ld PROJECT:ld64-224.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em
Library search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/
[...]
The -Xlinker option of gcc above just passes -v to ld. However:
ld -v
doesn't print the search path.
Mac version: $ ld -v 2, don't know how to get detailed paths.
output
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
I'm having difficulty with the linker when it comes to compiling a sample program that uses the POSIX aio library (e.g. aio_read(), aio_write(), etc) on Linux.
I'm running Ubuntu with a 2.6 kernel, and have used the apt-get utility to install libaio. But even though I'm linking with the aio library, the compiler still gives me linker errors.
root#ubuntu:/home# g++ -L /usr/lib/libaio.a aio.cc -oaio
/tmp/cc5OE58r.o: In function `main':
aio.cc:(.text+0x156): undefined reference to `aio_read'
aio.cc:(.text+0x17b): undefined reference to `aio_error'
aio.cc:(.text+0x191): undefined reference to `aio_return'
collect2: ld returned 1 exit status
Where are all these aio_x functions actually defined, if not in the library libaio.a?
I also had issues linking against libaio in spite of the aio package being correctly installed and the -lrt flag being present.
It turned out that placing -l flags later (for example, last) in the gcc command invocation sometimes fixes this issue. I stumbled upon this solution here on Stack Overflow.
I stopped doing this:
gcc -Wall -Werror -g -o myExe -lrt myExe.c
And started doing this:
gcc -Wall -Werror -g -o myExe myExe.c -lrt
EDIT: according the the man page, libaio.so is not the correct library to link to:
man aio_read
SYNOPSIS
#include <aio.h>
int aio_read(struct aiocb *aiocbp);
Link with -lrt.
so you should link with this:
g++ -lrt aio.cc -o aio
The way libraries work with gcc is like this:
-L adds directory dir to the list of directories to be searched for -l.
-l adds a library itself, if the file is named libsomename.so, you just use "-lsomename"
Does -L specify the search path and -l specifies the actual library?
You want -laio in order to link to libaio. The argument of -o is what you want the compiled executable to be called.
Try:
sudo apt-get install libaio-dev
Then make sure you specify -laio on the link line.
Okay, Evan Teran is correct - it worked when I linked with -lrt. It seems the aio_x functions are defined in a general POSIX extension library.
Thanks, Evan.