ld: undefined reference, but it should leave them unresolved - makefile

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).

Related

Undefined symbol with BoringSSL

I'm writing a test application with BoringSSL and when I execute it I get this error:
symbol lookup error: ./main: undefined symbol: SSL_CTX_set_min_proto_version
All needed libraries are getting linked in my makefile:
CC = g++
FLAGS = -Wall -g
INCLUDES = -I/home/denis/libraries/boringssl/include
LIBS = -L/home/denis/libraries/boringssl/build/crypto -L/home/denis/TLS-Bibliotheken/boringssl/build/ssl -lcrypto -lssl
OBJ = Main.o BoringSSLTest.o
# Link files
main: $(OBJ)
$(CC) $(FLAGS) -o main $(OBJ) $(LIBS)
# Compile files
Main.o: Main.cpp
$(CC) $(FLAGS) -c $(INCLUDES) Main.cpp
BoringSSLTest.o: BoringSSLTest.cpp BoringSSLTest.h
$(CC) $(FLAGS) -c $(INCLUDES) BoringSSLTest.cpp
clean:
$(RM) $(OBJ) main
When I look for the definition of the symbol with nm libssl.so | grep SSL_CTX_set_min_proto_version I see that it is not undefined (T).
Why does it not work?
It is probably loading a wrong version of libssl.so at run-time. Invoke ldd ./main to see where it loads libssl.so from.
When you use -L<dir> linker option to link shared libraries from a non-standard location you need the corresponding -Wl,-rpath=<dir> linker option to tell the run-time linker to load the library from there.

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.

How do I link static library and dynamic library at the same time?

I have written a makefile like the following:
COMPILER = g++
COMPILER_FLAGS = -c -g -O0 -Wall -w
EXEC=mhu9_mp3
LD = g++
LINKER = g++
mhu9_mp3 : mhu9_mp3.o teapot.o EasyBMP.o
$(LD) teapot.o mhu9_mp3.o EasyBMP.o -L./SOIL/lib -lSOIL -o mhu9_mp3 -L./usr/lib -lGL -lGLU -lglut -lGLEW
teapot.o : teapot.cpp teapot.h
$(COMPILER) $(COMPILER_FLAGS) teapot.cpp
mhu9_mp3.o : mhu9_mp3.cpp teapot.h
$(COMPILER) $(COMPILER_FLAGS) mhu9_mp3.cpp
EasyBMP.o : EasyBMP_1.06/EasyBMP.cpp
$(COMPILER) $(COMPILER_FLAGS) EasyBMP_1.06/EasyBMP.cpp
clean:
-rm -f *.o mhu9_mp3
where libSOIL.a is a static library (I linked it by using "-L./SOIL/lib -lSOIL") and -lGL -lGLU -lglut -lGLEW are dynamic libraries. I have linked them together at the same line. In my cpp file I have a function call that calls a function defined in SOIL.h . However, when I compiled I got this error:
undefined reference to `SOIL_load_image'
I'm pretty sure I have included the header file SOIL.h, and also I have linked in the static library libSOIL.a. So what is the reason for this error? I try adding a -static flag before the -lSOIL but the linker wrongly assumes other dynamics libraries are static. Is there any better ways of linking static and dynamic libraries at the same time?
Put the list of dynamic libraries before the list of static libraries.
Example:
$(LD) -L<path> -l<dynamiclib1> -l<dynamiclib2> -static -l<staticlib1> -l<staticlib2>
Counterpart of -static is -Bdynamic. So if you really have to, it could be something like
ld -o foo foo.o -static -lstaticlib -Bdynamic -ldynamiclib0 -ldynamiclib1
However, this makes sense only when both dynamic and static libraries are present. If only one exists, linker will chose one itself.
In your case, problem may be caused by wrong link order or by the fact that SOIL_load_image is indeed missing (verify it with nm or objdump).

Clang error while creating shared library

I want to compile a shared library on MBP and based on the advise given here, I have switched to clang (from gcc) to create the shared library. My makefile is:
CC = clang
CFLAGS = -c -fPIC -Wall -O3 -lpthread -g
BaseDir = /Users/admin/Prog/
Include = -I$(BaseDir)UMFPACK/Include -I$(BaseDir)AMD/Include -I$(BaseDir)SuiteSparse_config
Lib = -L$(BaseDir)UMFPACK/Lib -L$(BaseDir)AMD/Lib -L$(BaseDir)GotoBLAS2 -L$(BaseDir)SuiteSparse_config
AddFiles = -lumfpack -lamd -lgoto2 -lsuitesparseconfig
StaticLibs = $(BaseDir)GotoBLAS2/libgoto2.a $(BaseDir)UMFPACK/Lib/libumfpack.a $(BaseDir)AMD/Lib/libamd.a $(BaseDir)SuiteSparse_config/libsuitesparseconfig.a
all: TDS.o TDSJac.o ExtraRoutines.o CalcVFC.o TDS.h
$(CC) $(Include) $(Lib) $(AddFiles) -dynamiclib -lpthread -o libTDS.so $^ -lm -g $(StaticLibs)
TDS.o: TDS.c TDS.h
$(CC) $(Include) $(CFLAGS) $^
TDSJac.o: TDSJac.c TDS.h
$(CC) $(CFLAGS) $^
ExtraRoutines.o: ExtraRoutines.c TDS.h
$(CC) $(CFLAGS) $^
CalcVFC.o: CalcVFC.c TDS.h
$(CC) $(CFLAGS) $^
MexFile: TDSGateway.c
mex -g -largeArrayDims -ldl TDSGateway.c
Move:
mv libTDS.so ../../
mv TDSGateway.mexmaci64 ../../
What I do here is:
1) Only compile TDS.c, TDSJac.c, ExtraRoutines.c, and CalcVFC.c to create four corresponding object files.
2) Merging object files and creating a shared library using following command:
clang -I(Some folders) -L(Some folders) -l(Some libraries) -shared -lpthread -o libTDS.so TDS.o TDSJac.o ExtraRoutines.o CalcVFC.o TDS.h -lm -g
clang: error: cannot specify -o when generating multiple output files
As I am absolutely new to clang, I do not know what is wrong with Makefile. (If I replace CC=clang with CC=gcc, everything works good.)
I searched the internet with no success. Manual page of clang says nothing about shared library. I could not even get anything out of clang homepage. It is appreciated if help me to work around this problem.
Thanks for your help in advance.
I had yesterday almost the same problem.
But i never used cmake. I'm using an own makefile system of my company, so I just can tell you, what fixed the problem for me so far.
Clang has still some trouble with giving you the right hints on errorcase.
The linking error was:
/usr/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC
I solved the problem as I figgered out, that the -shared Parameter has to be behind the -o X.o parameters. As I see this is not made in your case, too. You should try that first.
In our case I also had to parse the LFlags with -WL, or -L, (afaik it doesn't matter which one you take but I read about a clang bug in relation to -Wl,).
But idk in how far you have to parse LFlags or not, when using cmake.
You've listed headers (TDS.h) as dependencies, which is fine, but you've then used $^ as inputs, which includes all dependencies. You should not list a header as an input. It should not be on the command-line at all, and in clang this is actually an error.
The error message is obscure but easy to resolve. You have 2 choices:
Be explicit instead of using $^. You could use a variable for inputs and another for dependencies, e.g.; or
Use intermediate .o files instead of .c files as inputs to a .so. The *.o files can depend on any .h they include.

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