This question already has an answer here:
32-bit absolute addresses no longer allowed in x86-64 Linux?
(1 answer)
Closed last month.
I'm a student currently taking a computer structures course and I have an assignement for writing in aseembly and C. I've found an issue I don't quite understand. We were given a makefile for running the program, and when connecting to our school's servers it works as intended. The issue arises when trying to use the same makefile on my personal machine. One of the assembly files (and likely more as I continue working) utilizes a .rodata section. Attempting to use the makefile as it was given results in the following error:
gcc -g -o a.out main.o run_main.o func_select.o pstring.o
/usr/bin/ld: func_select.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
make: *** [makefile:2: a.out] Error 1
attempting to add one of the following
-fpie -fPIE or -no-pie
in between
-o
and a.out
results in the following error
gcc -g -o -fPIE a.out main.o run_main.o func_select.o pstring.o
/usr/bin/ld: cannot find a.out: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [makefile:2: a.out] Error 1
I'm sorry if this is considered a silly question however I can't figuere it out.
The expectation was for the makefile to create all of the .o files and a.out, however the a.out file never works.
In addition writing the following: gcc -g -fPIE -o a.out main.o run_main.o func_select.o pstring.o still creates an error, specifically
gcc -g -fPIE -o a.out main.o run_main.o func_select.o pstring.o
/usr/bin/ld: func_select.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
make: *** [makefile:2: a.out] Error 1
As per man gcc:
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-Wpedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] [#file] infile...
-o requires outfile parameter. This should work:
gcc -g -fPIE -o a.out main.o run_main.o func_select.o pstring.o
Related
Error is as follows:
/usr/bin/ld: gfx.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: project] Error 1
and when I add -fPIC or -fPIE, nothing changes. I know that the gfx.o library works, since it was working previously and still works when I ssh on my server.
Make file is as follows:
project: project.c
gcc project.c gfx.o -lx11 -lm -fPIE -o -project
clean:
rm project
I tried to use -fPIE and -fPIC in the makefile. I also treid uninstalling and reinstalling gcc and binutills, but nothing worked.
I figured out that putting -no-pie in the Makefile solves the issue. I don't know if there is a more permanent and widespread fix, but it works.
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 am having an issue with a makefile for something I am making. My makefile looks like this
bag: main.o bow.o
gcc bow.o main.o -o bag
main.o: main.c bow.h
gcc -Wall -ansi -pedantic main.c -o main.o
bow.o: bow.c bow.h
gcc -Wall -ansi -pedantic -c bow.c -o -bow.o
I also have a header file called "bow.h" that is used in both bow.o and main.o. bow.h consists of 8 function definitions and 2 structs, bow.c contains the 8 functions and NO MAIN file. main.c is suppose to be a minimal main file so it only consists of
#include "bow.h"
When I run my makefile in the Terminal with
make
I get this message
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
makefile:2: recipe for target 'bag' failed
make: *** [bag] Error 1
What exactly does this mean, how is it caused and how can I fix it?
Even a minimal program (executable) needs a point to start. For a C program, this is the main() function. Thus, the linker seeks for that function (more precisely, it links the start-up object where main is an unresolved symbol), does not find it, and issues an error.
Thus, you have to provide a main(). Alternatively, you may not generate an executable but a library.
I am trying to resurrect on old OpenGL program on a Linux Mint system. I installed freeglut3-dev using Synaptic Package Manager. The compiler does not complain about not being able to find the glut include file anymore, but now I have other problems:
cc -Wall -o gears main.c draw_gears.c gl_drawing.c load_data.c normal.c prep_data.c -lglut
/usr/bin/ld: /tmp/ccfNsT0O.o: undefined reference to symbol 'glNewList'
//usr/lib/i386-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [gears] Error 1
Try this:
cc -Wall -o gears main.c draw_gears.c gl_drawing.c load_data.c normal.c prep_data.c -lglut -lGLU -lGL
I have a problem while trying to compile and link my program with "dmalloc".
bin
+--dmalloc
include
+--dmalloc.h
lib
+--libdmalloc.a
+--libdmallocth.a
main.c
I have the following directory structure
Now I try to compile my program with the following command:
gcc -Iinclude -Llib -ldmalloc -DDMALLOC main.c
/tmp/ccSDFmWj.o: In function `main':
main.c:(.text+0x29): undefined reference to `dmalloc_malloc'
collect2: ld returned 1 exit status
Okay, I get that there's a problem with linking the symbols, ld simply cannot find reference to dmalloc_malloc. However...
nm lib/libdmalloc.a | grep dmalloc_malloc
0000000000001170 T dmalloc_malloc
0000000000000fe0 t dmalloc_malloc.part.6
I am puzzled... The symbol is there in that library. Why does 'ld' has problem with it?
List the libraries last:
gcc -Iinclude -Llib -DDMALLOC main.c -ldmalloc