after upgrading to Ubuntu 11.10, I've found that many of my old and current developments can't be compiled anymore. I've reduced the problem to a simple example:
#include <X11/Xlib.h>
int main() {
Display* display = XOpenDisplay(":0.0");
XCloseDisplay(display);
return 0;
}
Compiling it using:
g++ -lX11 test.cpp
or
g++ -c -o test.o test.cpp
g++ -lX11 -o test test.o
Causes a failure to happen:
/tmp/ccBAOpzy.o: In function `main':
test.cpp:(.text+0x11): undefined reference to `XOpenDisplay'
test.cpp:(.text+0x21): undefined reference to `XCloseDisplay'
Any ideas? I've found that some linker stuff has changed in 11.10:
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
But still doesn't explain these problems.
g++ -lX11 -o test test.o
Above command is incorrect. Try this instead:
g++ test.o -lX11
Explanation of why the order matters here.
Also, you should never call your executables test on UNIX.
Related
I'm trying to get my head around how the linking process works when producing an executable. To do that I'm reading Ian Taylor's blog series about it, but a lot of it is beyond me at the moment - so I'd like to see how it works in practice.
At the moment I produce some object files and link them via gcc with:
gcc -m32 -o test.o -c test.c
gcc -m32 -o main.o -c main.c
gcc -m32 -o test main.o test.o
How do I replicate the gcc -m32 -o test main.o test.o stage using ld?
I've tried a very naive: ld -A i386 ./test.o ./main.o
But that returns me these errors:
ld: i386 architecture of input file `./test.o' is incompatible with i386:x86-64 output
ld: i386 architecture of input file `./main.o' is incompatible with i386:x86-64 output
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
./test.o: In function `print_hello':
test.c:(.text+0xd): undefined reference to `_GLOBAL_OFFSET_TABLE_'
test.c:(.text+0x1e): undefined reference to `puts'
./main.o: In function `main':
main.c:(.text+0x15): undefined reference to `_GLOBAL_OFFSET_TABLE_
I'm most confused by _start and _GLOBAL_OFFSET_TABLE_ being missing - what additional info does gcc give to ld to add them?
Here are the files:
main.c
#include "test.h"
void main()
{
print_hello();
}
test.h
void print_hello();
test.c
#include <stdio.h>
void print_hello()
{
puts("Hello, world");
}
#sam : I am not the best people to answer your question because I am a beginner in compilation. I know how to compile programs but I do not really understand all the details (https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools)
So, I decided this year to try to understand how compilation works and I tried to do, more or less, the same things as you tried a few days ago. As nobody has answered, I am going to expose what I have done but I hope an expert will supplement my answer.
Short answer : It is recommended to not use ld directly but to use gcc directly instead. Nevertheless, it is, as you write, interesting to know how the linking process works. This command works on my computer :
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o /usr/lib/crtn.o
Very Long answer :
How did I find the command above ?
As n.m suggested, run gcc with -v option.
gcc -v -m32 -o test main.o test.o
... /usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2 ... (many
options and parameters)....
If you run ld with these options and parameters (copy and paste), it should work.
Try your command with -m elf_i386 (cf. collect2 parameters)
ld -m elf_i386 test.o main.o
ld: warning: cannot find entry symbol _start; ....
Look for symbol _start in object files used in the full ld command.
readelf -s /usr/lib/crt1.o (or objdump -t)
Symbol table '.symtab' contains 18 entries: Num: Value Size
Type Bind Vis Ndx Name... 11: 00000000 0 FUNC
GLOBAL DEFAULT 2 _start
Add this object to your ld command :ld -m elf_i386 test.o main.o /usr/lib/crt1.o
... undefined reference to `__libc_csu_fini'...
Look for this new reference in object files. It is not so obvious to know which library/object files are used because of -L, -l options and some .so include other libraries. For example, cat /usr/lib/libc.so. But, ld with --trace option helps. Try this commandld --trace ... (collect2 parameters)At the end, you should findld -m elf_i386 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc_nonshared.a /lib/libc.so.6 /usr/lib/crti.oor shorter (cf. cat /usr/lib/libc.so) ld -m elf_i386 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o
It compiles but it does not run (Try to run ./test). It needs the right -dynamic-linker option because it is a dynamically linked ELF executable. (cf collect2 parameters to find it) ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o But, it does not run (Segmentation fault (core dumped)) because you need the epilogue of the _init and _fini functions (https://gcc.gnu.org/onlinedocs/gccint/Initialization.html). Add the ctrn.o object. ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o main.o /usr/lib/crt1.o /usr/lib/libc.so /usr/lib/crti.o /usr/lib/crtn.o./test
Hello, world
I just want to test -pg, the source file is very simple, my environment is
cygwin,
$ uname -a
CYGWIN_NT-10.0 SHA-LPLATOW 2.8.2(0.313/5/3) 2017-07-12 10:58 x86_64 Cygwin
$ vi pgtest.c
#include <stdio.h>
void main(void){
printf("hello, world\n");
}
no -pg compiling is OK.
$ gcc -c pgtest.c
$ gcc -o pgtest.exe pgtest.o
but -pg report error
$ gcc -pg -c pgtest.c
$ gcc -o pgtest.exe pgtest.o
pgtest.o:pgtest.c:(.text+0x1): undefined reference to `__fentry__'
pgtest.o:pgtest.c:(.text+0x1): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__fentry__'
pgtest.o:pgtest.c:(.text+0xe): undefined reference to `_monstartup'
pgtest.o:pgtest.c:(.text+0xe): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_monstartup'
collect2: error: ld returned 1 exit status
I have tried LDFLAGS, it is the same.
export LDFLAGS="-pg" ; gcc -o pgtest.exe pgtest.o
from the gcc info page
'-pg'
Generate extra code to write profile information suitable for the
analysis program 'gprof'. You must use this option when compiling
the source files you want data about, and you must also use it when
linking.
so if you want to do a separate compilation and linking you need to repeate the -pg
$ gcc -c pgtest.c -pg
$ gcc -o pgtest.exe pgtest.o -pg
This problem has bothered me for days.
After I compile and install ffmpeg , I try to build a demo using it, but it always fails.
The demo is:
#include "libavcodec/avcodec.h"
#include "libavformat/avformat.h"
int main(int argc,char *argv[]) {
av_register_all();
return 1;
}
With gcc main.c -o main.o, an error occurs: undefined reference to 'av_register_all'
Building with: gcc main.c -o main.o -lm -ld -lz -lavcodec -lavformat -lavutil, another error occurs: /usr/bin/ld: cannot find -ld
How can I resolve this?
Putting includes within extern "C" block may work.
extern "C"{
#include <libavcodec/avcodec.h>
#include <libavformat/avformat.h>
#include <libswscale/swscale.h>
}
As mentioned here
the order of libraries matters
so in your case the following hopefully should work:
gcc main.c -o main.o -lavformat -lavcodec -lavutil -lz -lm -lpthread
gcc filename.c -o outputfilename -lavformat -lavcodec -lavutil -lz -lm -lpthread -I'/usr/local/include' -lswresample
The above command will help to compile properly.
Have a look at how this project builds sample code.
The Makefile is pretty simple to follow.
It's work for me:
gcc <your source code> -o main -lavformat -lavcodec -lavutil -lm -lpthread -I'/usr/local/include' -lswresample
I'm trying to combine object files created from C++ files into an executable using gcc. Unfortunately, gcc is giving me thousands of undefined reference errors to strings, arrays, etc.
I am doing this on a Windows machine, so no terminal commands; only cmd commands.
I'm simply doing:
gcc a.o b.o c.o -o prgm.exe
What am I missing/doing wrong?
EDIT:
I recreated the .o files with g++ doing:
g++ a.cpp -g -c -Wall -std=c++0x -lSDLmain -lSDL -lSDL_image -lSDL_ttf -IC:\SDL-1.2.14\include -o a.o, where a.cpp and a.o are the directories where i keep the files, not the g++ directory
Then, I did g++ a.o b.o c.o -o prgm.exe. This gave dozens (I guess that's an improvement?) errors like
undefined reference to `_SDL_SetColorKey'
but I included SDL didnt I?
The final error from this is:
c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../li
bmingw32.a(main.o):main.c:(.text.startup+0xa7): undefined reference to `_WinMain
#16'
collect2.exe: error: ld returned 1 exit status
int main(int argc, char * argv[]) is in the code
You are trying to link a C++ program with the C linker. You need to use g++ instead of gcc.
Generally speaking gcc is for compiling/linking C, while g++ is for C++. IIRC compiling C++-code with gcc works by virtue of dispatching according to the file extension. Linking C++ code with gcc however does not work, since it won't link the C++ standard libraries, resulting in your undefined reference errors.
If this does not solve your problem, you might want to give us a more concrete description of your errors and your system.
Based upon your updates then I think you'd need to do the following:
g++ a.cpp b.cpp c.cpp -g -Wall -IC:\SDL-1.2.14\include -LC:\SDL-1.2.14\lib -std=c++0x -lSDLmain -lSDL -lSDL_image -lSDL_ttf -o prgm.exe
I'm guessing C:\SDL-1.2.14\lib exists based upon where the headers are located.
GCC is the C compiler. Your code is C++ so you need to use G++ to do the linking:
g++ a.o b.o c.o -o prgm.exe
This automatically adds the C++ libraries to the link line, resolving many if not all of your missing references.
I have searched high and low for answer to this issue. I am using boost 1.48 and the program is extremely simple, since I have broken it down to its simplest form in order to solve this issue.
#include <boost/filesystem.hpp>
int main(int argc, char **argv) {
return 0;
}
The g++ command executed from my Makefile is as follows:
g++ -m32 -Wall -o mapnik-test -L/usr/lib -I/usr/include -I/usr/include/freetype2 -lpthread -lboost_system mapnik-test.cpp
The complete list of errors during linking is as follows:
/tmp/ccIbmuee.o: In function `__static_initialization_and_destruction_0(int, int)':
mapnik-test.cpp:(.text+0x49): undefined reference to `boost::system::generic_category()'
mapnik-test.cpp:(.text+0x53): undefined reference to `boost::system::generic_category()'
mapnik-test.cpp:(.text+0x5d): undefined reference to `boost::system::system_category()'
collect2: ld returned 1 exit status
make: *** [mapnik-test] Error 1
I have found many people suffering from the same issue, but in most cases, the solution has been to provide the boost_system library in the LDFLAGS. As you can see from the g++ command line, I already have this specified. I have even tried explicitly linking against the libboost_system.a library to no avail. Am I the only person with this complaint?
Put the source file at the beginning of the command line.
Try
g++ -m32 -Wall mapnik-test.cpp -o mapnik-test -L/usr/lib -I/usr/include -I/usr/include/freetype2 -lpthread -lboost_system
The libraries should be specified only after the source file so that the linker can resolve the undefined references in the source file.