linking assembly object file with C object file on OS X and can't find symbol - macos

I have a library defined in libadd.asm, it exposes one "function" _add. I have a .c source file that refers to add and I'm trying to get the two object files to link, but am encountering this error regardless of the order in which I link the object files:
Undefined symbols for architecture x86_64:
"_add", referenced from:
_main in prog.o
Here's the code:
// prog.c
#include <stdio.h>
int add();
int main() {
printf("%d\n", add(4, 5));
return 0;
}
And here's the assembly file. It almost certainly doesn't respect the appropriate calling convention. I don't really understand what I should be doing to shuffle the values between registers. (That's what I was trying to figure out originally.)
; libadd.asm
_add:
add eax, edx
ret
Here's what I'm using to the tiny project. I'm intentionally shadowing the implicit .c.o rule with one that does as little as possible and ignores *FLAGS. I'm using cc to drive the linker because that's the simplest way I know to link in the c runtime/standard library/whatever it's called. I've always tried linking with prog.o and libadd.o in the other order.
all: prog
prog: prog.o libadd.o
$(CC) -o prog $^
%.o: %.asm
nasm -f macho64 -o $# $<
%.o: %.c
$(CC) -c -o $# $<
clean:
$(RM) $(wildcard *.o)
running make produces the following output
cc -c -o prog.o prog.c
nasm -f macho64 -o libadd.o libadd.asm
cc -o prog prog.o libadd.o
Undefined symbols for architecture x86_64:
"_add", referenced from:
_main in prog.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [prog] Error 1
Exit 2
libadd.o gets assembled successfully and appears to have the right symbol in it.
% nm libadd.o
0000000000000000 t _add
Why is ld complaining that it can't find the symbol?

Related

How to modify makefile for openMP inclusion

HI everybody I am a beginner for both openMP and makefile. Here is my problem.
I usually compile simple openMP code via terminale using:
g++-10 -o file.exe -fopenmp file.cxx
Now I want to modify a code, which consists in many file linked together, adding openMP libraries. Indeed I have to change the already existing makefile and I have no idea how to do it. The openMP libraries are used only in the file "esercizio1.1.cxx".
Here the makefile:
esercizio1.1 : esercizio1.1.o random.o
g++ -o esercizio1.1 esercizio1.1.o random.o
esercizio1.1.o : esercizio1.1.cxx funzioni.h random.h
g++ -c -o esercizio1.1.o esercizio1.1.cxx
random.o : random.cxx random.h
g++ -c -o random.o random.cxx
clean:
rm esercizio1.1
Here an example of how I tried to modify my makefile. I renamed my file and I added
g++-10 -fopenmp
to all the line at the same time, to all the line one per time. but still does not work. Here an example:
esercizio : esercizio.o random.o
g++-10 -fopenmp esercizio.o random.o -o esercizio
esercizio.o : esercizio.cc funzioni.h random.h
g++-10 -fopenmp esercizio.cc -o esercizio.o
random.o : random.cc random.h
g++ random.cc -o random.o
clean:
rm esercizio
Here is the error:
Undefined symbols for architecture x86_64:
"__ZN6Random6RannyuEv", referenced from:
_main._omp_fn.0 in ccA635Wn.o
"__ZN6Random8SaveSeedEv", referenced from:
_main in ccA635Wn.o
"__ZN6Random9SetRandomEPiii", referenced from:
_main in ccA635Wn.o
"__ZN6RandomC1Ev", referenced from:
_main in ccA635Wn.o
"__ZN6RandomD1Ev", referenced from:
_main in ccA635Wn.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [esercizio.o] Error 1
Does it exist a guide for makefile beginner?
Anyway I would appreciate if someone helped me. Thanks in advance.
"C++ compilers are picky and may come with different ABIs, thus mixing different C++ compilers in the same project isn't advised. You are compiling random.cc with g++, which on macOS is a symlink to Apple's clang++. Use g++-10 instead. Also, g++ -o random.o random.cc produces an executable file, not an object file. Leave it as g++-10 -c -o random.o random.cc."
credits to Hristo Iliev. Thank you.

How to run manually produce an elf executable using ld?

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

ld: undefined reference, but it should leave them unresolved

I am unable to produce a library, which works with another library (SDL). I am using MinGW for make, and ld to link. I am confused because a) it shouldn't be trying to link in these libraries, but do this later when someone links my library in as well; and b) even if I do link in the SDL libraries, it still can't find the SDL functions (SDL_GetTicks, SDL_Delay) it's looking form -- the errors are the same. Also note that some of the missing items are from std.
Here are the errors. As you can see, I'm trying various flags on ld to make it not try to resolve references, but w/o success yet.
C:\Users\...\mcve>make
g++ -c -c -I../../../external/SDL2/include -I../include -o mcve.o mcve.cpp
ld -G --unresolved-symbols=ignore-all --warn-unresolved-symbols -o libmcve.a mcve.o
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x8): undefined reference to `SDL_GetTicks'
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x23): undefined reference to `SDL_GetTicks'
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x2f): undefined reference to `SDL_Delay'
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x46): undefined reference to `std::ios_base::Init::~Init()'
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x67): undefined reference to `std::ios_base::Init::Init()'
C:\MinGW\bin\ld.exe: mcve.o:mcve.cpp:(.text+0x73): undefined reference to `atexit'
Here's my source file:
#include <SDL.h>
#include <iostream> //If I take this out, I no longer get the
//unresolved references to std::ios_base::Init::Init,
// std::ios_base::Init::~Init, and atexit
Uint32 time;
void doSomething ()
{
if (time > SDL_GetTicks ())
SDL_Delay (time - SDL_GetTicks());
}
This is the Makefile. If I uncomment the rest of the LDFLAGS and let the SDL libraries link in, it does not change the output.
CFLAGS =-c -I../../../external/SDL2/include -I../include
LDFLAGS = --unresolved-symbols=ignore-all --warn-unresolved-symbols #-L. -lSDL2 -lSDL2_ttf -lSDL2_image -lSDL2_mixer
# Files
SOURCE_FILES= mcve.cpp
OBJECT_FILES= mcve.o
libmcve.a: $(OBJECT_FILES)
ld $(LDFLAGS) -o $# $^ -G
$(OBJECT_FILES): %.o: $(SOURCE_FILES)
g++ -c $(CFLAGS) -o $# $<
You are attempting to create the static library libmcve.a from the object file
mcve.o using the linker ld.
The linker cannot produce a static library. A static library is merely
an ar archive of object files that is produced by ar.
The recipe to create or update the static library in your makefile would be:
libmcve.a: $(OBJECT_FILES)
rm -f $# # Delete archive if already exists
ar rcs $# $^ # Recreate archive with contents $(OBJECT_FILES)
BTW, note that you are passing the -c option in your compilation commands
twice:
g++ -c -c -I../../../external/SDL2/include -I../include -o mcve.o mcve.cpp
That is because you have included it in your CFLAGS setting:
CFLAGS =-c -I../../../external/SDL2/include -I../include
(where it should not be), and also in your compilation recipe:
g++ -c $(CFLAGS) -o $# $<
(where it should be).

ld can't find library given -L

I have an object file main.o, and need to link it against a shared library at ./libsvm/libsvm.so.2. I have the following Makefile but it doesn't work for me. Library path has been specified in -L./libsvm but gcc -lsvm still can't find the shared library (libsvm.so.2).
This is my Makefile:
CC = g++ -g
CFLAGS = -Wall
HEADERS = -I./libsvm
OBJ = main.o
LIBS = -L./libsvm
all: lib $(OBJ)
$(CC) $(LIBS) -lsvm $(OBJ) -o main
%.o: %.c
$(CC) $(CFLAGS) $(HEADERS) -c -o $# $<
lib:
cd libsvm; make
It just works if link them directly, as in
ld main.o libsvm/libsvm.so.2 -o main
I wonder what's wrong in the Makefile. Error message is the following
g++ -g -L./libsvm -lsvm main.o -o main
ld: library not found for -lsvm
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [all] Error 1
-lsvm means use the file svm.so
But your library file has name svm.so.2. (Version 2)
So either rename or make a symbolic link with
ln -s svm.so.2 svm.so
Now the makefile should work.

Linking C program with C++ library (GCC 4.5+)

I was using gcc/g++ 4.4 to build my project, and now i'm trying to switch to gcc 4.5, but getting odd "undefined reference" errors when linking C program with C++ library. Here is my testcase:
source.c
#ifdef LIBRARY
extern "C" int one() {
return 1;
}
#else
#include <stdio.h>
int one();
int main() {
printf ("%i\n", one());
return 0;
}
#endif
Makefile
all: clean program
program: source.c library.so
$(CC) -L. -lrary -o $# $<
library.so: source.c
$(CXX) -shared -DLIBRARY -fPIC -o $# $<
.PHONY: clean
clean:
rm -f program library.so
Everything works fine while using GCC 4.4:
$ CXX=g++-4.4 CC=gcc-4.4 make
rm -f program library.so
g++-4.4 -shared -DLIBRARY -fPIC -o library.so source.c
gcc-4.4 -L. -lrary -o program source.c
But not working while using GCC 4.5:
$ CXX=g++-4.5 CC=gcc-4.5 make
rm -f program library.so
g++-4.5 -shared -DLIBRARY -fPIC -o library.so source.c
gcc-4.5 -L. -lrary -o program source.c
/tmp/ccC4kNHP.o: In function `main':
source.c:(.text+0xa): undefined reference to `one'
collect2: ld returned 1 exit status
make: *** [program] Error 1
Or GCC 4.6:
$ CXX=g++-4.6 CC=gcc-4.6 make
rm -f program library.so
g++-4.6 -shared -DLIBRARY -fPIC -o library.so source.c
gcc-4.6 -L. -lrary -o program source.c
/tmp/ccxNRNSS.o: In function `main':
source.c:(.text+0xa): undefined reference to `one'
collect2: ld returned 1 exit status
make: *** [program] Error 1
Anyone can shed a light on this issue?
PS: This one was built using 4.6:
$ nm -D library.so
w _Jv_RegisterClasses
0000000000201010 A __bss_start
w __cxa_finalize
w __gmon_start__
0000000000201010 A _edata
0000000000201020 A _end
00000000000005a8 T _fini
0000000000000458 T _init
000000000000055c T one
It is because of linker's --as-needed option being used i.e. the library is not linked until a symbol is actually found in the source which is part of the library. You should move your source files before linking in the compilation command. You could try changing your Makefile rule program from $(CC) -L. -lrary -o $# $< to $(CC) $< -L. -lrary -o $#. Or alternatively, you could pass --no-as-needed to the linker i.e. $(CC) -Wl,--no-as-needed -L. -lrary -o $# $<. The first method is better suited to be used.
Hope this helps!

Resources