|
Home > Archive > Unix Programming > November 2004 > GNU make ; whole-project Makefile and shared libraries
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
GNU make ; whole-project Makefile and shared libraries
|
|
| fwojcik+ggluse2@besh.com 2004-11-22, 5:51 pm |
| Hi. I'm trying to convert our existing rescursive make system into a
whole-project makefile. I'm using GNU make v3.75 and gcc 2.95.2 on a
BSDi system, and none of that is negotiable for my purposes.
I've run into the following problem with regards to shared libraries. A
greatly
simplified version of our flattened (post "include") Makefile looks
like:
-------------------------begin paste-------------------------
LIBS = libs/lib1.a libs/lib2.so
# main programs
OBJ := p1/prog1.o
p1/prog1: $(OBJ) $(LIBS)
$(CC) -o $@ $^
OBJ := p2/prog2.o
p2/prog2: $(OBJ) $(LIBS)
$(CC) -o $@ $^
# libraries
libs/lib1.a: libs/lib1.o
ar ru $@ $^
ranlib $@
libs/lib2.so: libs/lib2.so
$(CC) -shared -o $@ $^
-------------------------begin paste-------------------------
This almost works great. The problem is that the two programs (prog1
and prog2)
have a pathname embedded for lib2 (ldd shows "libs/lib2.so" instead of
"lib2.so") which utterly breaks things at runtime.
I can't find a way to have variables in commands be evaluated
immediately. Having a different OBJ_foo for each program would be
hideously ugly and unacceptable. Therefore, I appear to be stuck using
automatic variables.
I've looked at flags for ld (I'm on a BSDi system), and can't see a way
to
strip the pathnames of libraries passed in. Using VPATH in some fashion
might work, except that "true" VPATH support wasn't until make 3.76.
How do I get this to work?
| |
| Grant Taylor 2004-11-23, 2:53 am |
| fwojcik+ggluse2@besh.com writes:
> OBJ := p2/prog2.o
> p2/prog2: $(OBJ) $(LIBS)
> $(CC) -o $@ $^
> libs/lib1.a: libs/lib1.o
> libs/lib2.so: libs/lib2.so
> This almost works great. The problem is that the two programs (prog1
> and prog2) have a pathname embedded for lib2 (ldd shows
> "libs/lib2.so" instead of "lib2.so") which utterly breaks things at
> runtime.
You could replace the $^ invokation with an appropriate soup of gnu
make string functions. If 3.75's functions aren't up to snuff (it
does keep growing new functions, and 3.75 was a while ago), use
`backticks` to run a spot of shell or a helper program in the
commandline.
Perhaps something like this:
$(CC) -o $@ $(addprefix -L,$(dir $^)) $(addprefix -l,$($(basename $(notdir $^))))
ie -Llibs ie -llib1 -llib2
Depending on what BSDi does and how your libraries [inter]depend, you
may find yourself having to monkey with more linker options than just
-L to get it quite right...
--
Grant Taylor
Embedded Linux Consultant
http://www.picante.com/
|
|
|
|
|