makefile gcc custom dynamic lib linking issue with .so file

Question

Guys I'm having a very hard time trying to make a custom .so file be correctly linked with the a another code file.

Where is the Makefile of the who creates the .so file:

#the compiler
CC = gcc

#the standart ompilation flags of the project
CFLAGS = -O3 -Wall -Wno-unused-variable -Wno-unused-but-set-variable -Wno-implicit-function-declaration

#path to the folder's root, where the holy not build framework is. Relate to this Makefile
PREPATH = ../

#Path to the SDL, SDL_image and Lua includes and libs
SDL2INCLUDES = -I $(PREPATH)SDL2/include
SDL2LIBS = $(PREPATH)SDL2/lib/libSDL2-2.0.so.0 $(PREPATH)SDL2/lib/libSDL2_test.a $(PREPATH)SDL2/lib/libSDL2-2.0.so.0.2.1 $(PREPATH)SDL2/lib/libSDL2main.a $(PREPATH)SDL2/lib/libSDL2.a $(PREPATH)SDL2/lib/libSDL2.so
SDLIMAGE2INCLUDES = -I $(PREPATH)SDL2/SDL_image
SDLIMAGE2LIBS = $(PREPATH)SDL2/lib/libSDL2_image-2.0.so.0 $(PREPATH)SDL2/lib/libSDL2_image.so $(PREPATH)SDL2/lib/libSDL2_image-2.0.so.0.0.0 $(PREPATH)SDL2/lib/libSDL2_image.a
LUAINCLUDES = -I $(PREPATH)lua/
LUALIB = -L $(PREPATH)lua/ -llua -lm

#Where to put the compiled program
COMPILEPATH = $(PREPATH)BINARIES/



#Build options

build: NLF.o
    cp ./*.o $(COMPILEPATH)
    $(CC) -shared $(CFLAGS) $(SDL2INCLUDES) $(SDL2LIBS) $(SDLIMAGE2INCLUDES) $(SDLIMAGE2LIBS) $(LUAINCLUDES) $(LUALIB) $(COMPILEPATH)*.o -o $(COMPILEPATH)libNLF.so

NLF.o: NLF_osservice.o NLF_Error.o NLF_event.o NLF.h.gch
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) -fPIC -c NLF.c

NLF.h.gch: NLF.h
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) NLF.h

NLF_osservice.o: NLF_osservice.h.gch
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) -fPIC -c NLF_osservice.c
NLF_osservice.h.gch:
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) NLF_osservice.h

NLF_Error.o: NLF_error.h.gch
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) -fPIC -c NLF_error.c
NLF_error.h.gch:
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) NLF_error.h

NLF_event.o: NLF_event.h.gch
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) -fPIC -c NLF_event.c
NLF_event.h.gch:
    $(CC) $(CFLAGS) $(SDL2INCLUDES) $(SDLIMAGE2INCLUDES) $(LUAINCLUDES) $(NLFINCLUDES) NLF_event.h  



#cleaning options

clean-build:
    rm -f -v $(COMPILEPATH)*.o

clean-hard clean-all:
    rm -f -v ./*.o ./*.h.gch
    rm -f -v $(COMPILEPATH)*.o $(COMPILEPATH)*.so

clean-soft clean-all-but-so:
    rm -f -v ./*.o ./*.h.gch

it's a bit long, but it's not hard ^^" This one compiles normally and create the "libNLF.so" file in the "BINARIES" folder. To be sure a run the command "nm -g libNLF.so | grep NLF", and it gives me between other things, this line:

0000000000001100 T NLF_init

Now lets to the problematic Makefile:

CC = gcc
CFLAGS = -O3
PREPATH = ../

SDL2INCLUDES = -I $(PREPATH)SDL2/include
SDL2LIBS = -L $(PREPATH)SDL2/lib/libSDL2-2.0.so.0 -L $(PREPATH)SDL2/lib/libSDL2_test.a -L $(PREPATH)SDL2/lib/libSDL2-2.0.so.0.2.1 -L $(PREPATH)SDL2/lib/libSDL2main.a -L $(PREPATH)SDL2/lib/libSDL2.a -L $(PREPATH)SDL2/lib/libSDL2.so
SDLIMAGE2INCLUDES = -I $(PREPATH)SDL2/SDL_image
SDLIMAGE2LIBS = -L $(PREPATH)SDL2/lib/libSDL2_image-2.0.so.0 -L $(PREPATH)SDL2/lib/libSDL2_image.so -L $(PREPATH)SDL2/lib/libSDL2_image-2.0.so.0.0.0 -L $(PREPATH)SDL2/lib/libSDL2_image.a
#LUAINCLUDES = -I $(PREPATH)lua/
#LUALIB = -L $(PREPATH)lua/ -llua -lm

NLFINCLUDES = -I $(PREPATH)NLF_SCR/
NLFLIB = -L ../BINARIES/libNLF.so


build:
    $(CC) $(CFLAGS) auto_genareted_code.c $(NLFINCLUDES) $(SDL2INCLUDES) $(NLFLIB) $(SDL2LIBS) -o auto_genareted_code

and the GCC gives me:

auto_genareted_code.c:(.text.startup+0x7): undefined reference to `NLF_init' and all other funtions from libNLF.so are in the same situation.

does some one knows what the hack in going on?

The `-L` option to `gcc` adds an entry to the library search path. This is a search path for *libraries*, not for *functions*, so it does not make sense to name individual library files that way. It certainly does not cause them to be linked. If you intend to give full paths to all the libraries then just give the library file names, without the `-L`. — John Bollinger, Feb 09 '16 at 20:54
On the other hand, the conventional way of specifying libraries would follow a pattern similar to this: `NLFLIB = -L../BINARIES -lNLF`. The `-L` specifies an extra directory to search, and the `-l` names a specific library to link, less the initial "lib" and the extension. — John Bollinger, Feb 09 '16 at 20:59
to be very honest with you, i still do not fully understand why it do not work. But I did what you said and it worked!! =D thanks so much, a spend the last 2 days in it kkkkkk ^^" — Leonardo Da Vinci, Feb 09 '16 at 21:04

score 0 · Answer 1 · answered Feb 09 '16 at 21:05

Adding to John Bollinger's solution, remember to put libraries linking at the end of compiler command, as order is important for library linking.

http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o' searches libraryz' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded.

makefile gcc custom dynamic lib linking issue with .so file

1 Answers1