[SOLVED] Moving to add makefiles. Struggling with libraries
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Moving to add makefiles. Struggling with libraries
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.
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"
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.
Last edited by sundialsvcs; 06-07-2023 at 07:54 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.
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.
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.
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.
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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.