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!
Related
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.
I am facing issues with a make command. I am compiling Scilab on RHEL for ppc64. The ./configure went well, now when I did make all, I have an issue when compiling the module umfpack. I can reproduce this error by entering the modules/umfpack folder, and by typing there make all. This is the output:
enter[root#rhel70-misurio umfpack]# /bin/sh ../../libtool --tag=CC --mode=link gcc -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -g -O2 -version-number 5:5:1 -Wl,--no-as-needed -o libsciumfpack.la -rpath /usr/local/lib/scilab sci_gateway/c/libsciumfpack_la-gw_umfpack.lo sci_gateway/c/libsciumfpack_la-sci_res_with_prec.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chdel.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chfact.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chget.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chinfo.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chsolve.lo sci_gateway/c/libsciumfpack_la-sci_umf_ludel.lo sci_gateway/c/libsciumfpack_la-sci_umf_lufact.lo sci_gateway/c/libsciumfpack_la-sci_umf_luget.lo sci_gateway/c/libsciumfpack_la-sci_umf_luinfo.lo sci_gateway/c/libsciumfpack_la-sci_umf_lusolve.lo sci_gateway/c/libsciumfpack_la-sci_umfpack.lo libsciumfpack-algo.la -L-lumfpack -lsuitesparseconfig -lumfpack -lpthread -ldl -lcurses -lm
../../libtool: line 6000: cd: -l: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
libtool: link: cannot determine absolute directory name of `-lumfpack'
So it is apparent that somewhere the code is doing "cd -"something. But where...? this is folder where I am.
[root#rhel70-hostname umfpack]# ls
etc libsciumfpack-algo.la make_all_log sci_gateway umfpack.iss
examples license.txt Makefile src UMFPACK_license.txt
help locales Makefile.am TAUCS_license.txt
includes macros Makefile.in tests
Which are the candidates, in your opinion, where I have to investigate where the mistake is? What would you do in my place to debug?
Thanks!
Many thanks for your suggestions! I went into the libtool file and indeed I found that at line 6'000 there was this line of code:
absdir=`cd "$dir" && pwd`
test -z "$absdir" && \
func_fatal_error "cannot determine absolute directory name of \`$dir'"
And I realised that it was doing "cd -lumfpack" in the script. That was an input I had given to the ./configure script, in which I had to explicitly provide the libumfpack and libsuitesparseparseconfig as an option, since it was using other libraries by default. In that option, I had given:
--with-umfpack-library="-lumfpack -lsuitesparseconfig"
so then make was doing "cd -lumfpack". So I thought about providing the absolute path of both libraries! So I gave as input:
--with-umfpack-library="/usr/local/lib/libumfpack.a /usr/local/lib/libsuitesparseconfig.a"
And it successfully ran the configure script and the make.
Another "solution" would have been to remove the umfpack libraries altogether with the option to the configure script:
--without-umfpack
Hope it helps future programmers compiling Scilab!
Honestly, I think another way could have been feasible, that is specifiying the libumfpack and libsuitesparseconfig libraries in the configure script directly, but I didn't have time then to investigate this. If I will do, I will update this post.
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
I'm a dumb newbie.
I've got a file named file.c with the functions my_putstr(char *) and my_strlen(char *)
my_putstr() writes the parameter with write() (unistd.h)
I wanted to create a library from file.c so I did :
gcc -fPIC -c file.c
gcc -shared -o libfile.so file.o
Then I created a main.c file and called my_putstr() from it.
I tried to compile and link my .so
gcc -L. -lfile main.c -o test
But I got an undefined reference to my_putstr()
I tried to create a .h with my_putstr() and my_strlen() in it, and include it to the main but I got the same error.
Sorry for stupid questions.
Havaniceday.
Your question suffers lack of information, but I can suggest you at first try
gcc main.c ./libfile.so -Wl,-rpath . -o test
If this will fail, you have something wrong with your sources.
If everything is ok at this point, then try
gcc main.c -L . -lfile -Wl,-rpath . -o test
If this will output undefined reference, then probably you already have something like libfile.a without my_putstr(may be from previous experiments) in your lib path.
If everything is ok with it, then your linker is sensible to order in which libraries is supplied to command string, and you must remember, then library always comes after object, that uses this library.
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.