[SOLVED] Moving to add makefiles. Struggling with libraries

jmgibson1981 · 06-06-2023, 10:38 PM

I managed to get my library package makefile to work just fine. However this program I'm working on requires that library. I have that library makefile set to install the header in /usr/local/include and the .so file in /usr/local/lib.

Now I am having trouble with the gcc syntax. Just missing something. I get undefined references to every single library call involving my library in /usr/local. Here is the makefile as it sits right now.

Code:

.DEFAULT_GOAL := build

# compiler

GCC = gcc

# linker flags

LF1 = -Wall
LF2 = -Werror

LIB = /usr/local

BIN = basicbanker

build:
	@echo "compiling and building binary"
	
	@${GCC} -c ${LF1} ${LF2} *.c -llib-jmgeneral
	@${GCC} *.o -I${LIB}/lib -L${LIB}/lib -o ${BIN}
  
install:
	@echo "installed binary to ${LIB}/bin"
	@cp ${BIN} ${LIB}/

uninstall:
	@rm ${LIB}/${BIN}
	@echo "removed binary from ${LIB}"
  
clean:
	@rm ./*.o
	@rm ${BIN}
	@echo "directory cleaned for next compilation"

I've added /usr/local/lib to my ld.so.conf.d but I may have misunderstood so it's probably wrong. Been tinkering for a bit but unable to get a build via make / gcc utilizing my libraries. Any help would be appreciated.

*EDIT* Forgot to mention calling the header like so.

Code:

#include <lib-jmgeneral.h>

in the source files.

NevemTeve · 06-06-2023, 11:20 PM

Change this:

Code:

	@${GCC} -c ${LF1} ${LF2} *.c -llib-jmgeneral
	@${GCC} *.o -I${LIB}/lib -L${LIB}/lib -o ${BIN}

Into this:

Code:

	
	@${GCC} -c -I${LIB}/include ${LF1} ${LF2} *.c 
	@${GCC} -L${LIB}/lib -Wl,-rpath,${LIB}/lib -o ${BIN} *.o -llib-jmgeneral

jmgibson1981 · 06-07-2023, 12:00 AM

Ok thank you that solved it. I gradually stripped it to minimal. Ended up with these lines. I did have to tinker with the -l flag a bit. Some googling led to me to realize it autocompletes the lib part so the below works now.

Makefile working totally after testing a few times.

Code:

.DEFAULT_GOAL := build

# compiler

GCC = gcc

# linker flags

LF1 = -Wall
LF2 = -Werror

LIB = /usr/local

BIN = basicbanker

build:
	@echo "compiling and building binary"
	@${GCC} -c ${LF1} ${LF2} *.c
	@${GCC} -L${LIB}/lib -o ${BIN} *.o -l-jmgeneral -lsodium
  
install:
	@echo "installed binary to ${LIB}/bin"
	@cp ${BIN} ${LIB}/bin/

uninstall:
	@rm ${LIB}/bin/${BIN}
	@echo "removed binary from ${LIB}/bin"
  
clean:
	@rm ./*.o
	@rm ${BIN}
	@echo "directory cleaned for next compilation"

pan64 · 06-07-2023, 02:01 AM

you need to split it into more parts, like:

Code:

... 

C_FILES= <list of your .c files>
O_FILES=$(C_FILES:.c=.o)

build: $(BIN)
$(BIN): $(O_FILES)
    @echo "building binary"
    @${GCC} -L${LIB}/lib -o ${BIN} $(O_FILES) -l-jmgeneral -lsodium

.c.o:
    @echo compiling $@
    @${GCC} -c -I${LIB}/include ${LF1} ${LF2} $< -o $@

...

(not tested)

EdGr · 06-07-2023, 01:39 PM

jmgibson1981 - On larger projects, you will want a build system. I recommend Meson. It will save time.
Ed

sundialsvcs · 06-07-2023, 07:32 PM

I agree with EdGr. While "Makefiles" are legendary, they are still tedious to set up and prone to error (which isn't apparent at the time) ... and, "you have better things to do."

make was "terrific in the 1970's, when computers could barely get out of their own way." But there are much better strategies now. And, they're even easier to use, even on your own "home" projects. These tools take, shall we say, a more "holistic" approach to the problem.

pan64 · 06-08-2023, 12:50 AM

Quote:

Originally Posted by sundialsvcs

I agree with EdGr. While "Makefiles" are legendary, they are still tedious to set up and prone to error (which isn't apparent at the time) ... and, "you have better things to do."

make was "terrific in the 1970's, when computers could barely get out of their own way." But there are much better strategies now. And, they're even easier to use, even on your own "home" projects. These tools take, shall we say, a more "holistic" approach to the problem.

No, I don't agree with you.
Make is the (almost) perfect tool to make software, that was very well designed. Unfortunately people don't waste their time to learn it, therefore in most cases it is not used properly. But that is another topic.

astrogeek · 06-08-2023, 01:34 AM

Quote:

Originally Posted by pan64

No, I don't agree with you.
Make is the (almost) perfect tool to make software, that was very well designed.

Agreed!

Quote:

Originally Posted by pan64

Unfortunately people don't waste wisely allocate their time to learn it, therefore in most cases it is not used properly. But that is another topic.

Fixed that for you!

GazL · 06-08-2023, 08:38 AM

I recently wasted/wisely allocated (delete as applicable) some time to learning ninja. I really like it, but I'm not a fan of the frontends such as cmake and meson. I've been hand-crafting ninja.build files here and while they're a little over verbose I do like the syntax and they're very easy to understand. Also, ninja is written in C, meaning there's no dependency on a python runtime unlike some of the other build systems.

Mostly, for a quick and dirty I still use Makefiles, relying on the implicit rules a lot of the time. It's only when you try and get clever that makefiles become unwieldy and hard to understand.

jmgibson1981 · 06-08-2023, 08:52 AM

I appreciate the various viewpoints. I'll definitely be looking into these options. In this particular case though my total package is a header and 3 source files. So I didn't see a need or reason to go to big. I can see the value for bigger projects though.

NevemTeve · 06-09-2023, 12:31 AM

Off: interesting reading about `make`:
https://accu.org/journals/overload/14/71/miller_2004/

pan64 · 06-09-2023, 01:16 AM

Quote:

Originally Posted by NevemTeve

Off: interesting reading about `make`:
https://accu.org/journals/overload/14/71/miller_2004/

That is wrong (or just misleading). Actually the title itself is wrong. Recursive make is not harmful, but the usage of make system without knowing how to do that is harmful. But it is valid for everything, not only make. And it is written in that article too:

Quote:

It must be emphasized that this paper does not suggest that make itself is the problem. This paper is working from the premise that make does not have a bug, that make does not have a design flaw. The problem is not in make at all, but rather in the input given to make – the way make is being used.

astrogeek · 06-09-2023, 01:58 AM

Quote:

Originally Posted by NevemTeve

Off: interesting reading about `make`:
https://accu.org/journals/overload/14/71/miller_2004/

You can also find it here in PDF format.

I first read that article after a brief mention in the O'Reilly book Managing Projects With GNU Make (3rd Ed. 2004 if that matters). That article left as much of an impression on my own habits as the book did, and I avoid recursive Makefiles as a result. But as already mentioned and as stressed in the paper itself:

Quote:

This paper is working from the premise that make does not have a bug, that make does not have a design flaw. The problem is not in make at all, but rather in the input given to make – the way make is being used.

While recursive Make can be done right, I encountered problems often enough, and avoided them easily enough by avoiding recursive Makefiles that I simply avoid recursion in Makefiles as a general principle. (My own projects and work environment allow that easily, others may find it more difficullt.)

I use Make often but am certainly not expert, or probably even very competent, truth be told... but I usually (always?) get it to work for my projects with reasonable effort and consider it indispensable. The following, taken from the linked paper has proven good advice for myself.

Quote:

If make doesn’t do what you expect it to, it’s a good chance the makefile is wrong.
From BSD Make tutorial

Thanks for the reminder.

EdGr · 06-09-2023, 11:45 AM

The takeaway is that tracking more than a small number of dependencies is a job for a computer.

Ed

pan64 · 06-10-2023, 03:30 AM

Quote:

Originally Posted by EdGr

The takeaway is that tracking more than a small number of dependencies is a job for a computer.

Ed

The dependencies should be defined by the designer(s) or developer(s). They know what they want, the computer has no real chance to find it out.
But actually we have some make system implementations which can do something similar, like clearmake and emake, at least they can detect and follow the [existing] dependencies. Even if they were not explicitly specified in a makefile. Unfortunately they are all payware.