How do I set the LD_LIBRARY_PATH env variable from a Makefile?
I have some source code that links to a shared library that in turn links to a different shared library (more than 1). The Makefile for building the application only knows about the first shared library.
If I want to build this, I have to specify:
#export LD_LIBRARY_PATH=/path/to/the/shared/libs (for bash)
and that works fine.
However, I would like to do this from the Makefile itself.
Yes, "export" is the correct directive to use. It is documented in detail here. This is the same mechanism as make itself uses to propagate variables to sub-makes. The drawback is that you cannot selectively pass down the variable to some commands and not to others.
There are two other options I can think of:
Using .EXPORT_ALL_VARIABLES (specify as a target somewhere), causes all variables to be exported to the environment of sub-commands.
Specify on the command line:
foo:
EXPORTEDVAR=somevalue gcc $< -o $#
If you don't want to export the LD_LIBRARY_PATH variable within the makefile (e.g. because you have recursive Makefiles which all add to the variable), you can keep it bound to all calls to your compiler and linker.
Either you add it directly to all gcc and ld calls within your target rules, e.g.
my_target: my_target.o
LD_LIBRARY_PATH=/my/library/path gcc -o my_target my_target.o
or you set the global make variables that define the compilers include the path, e.g.:
CC=LD_LIBRARY_PATH=/my/library/path gcc
CPP=LD_LIBRARY_PATH=/my/library/path gcc
CXX=LD_LIBRARY_PATH=/my/library/path gcc
I chose gcc as compiler but of course you can use any compiler you like.
I had the same problem, I had to export LD_LIBRARY_PATH as you did:
export LD_LIBRARY_PATH=/path/to/the/shared/libs ; my_command
My friend showed me an alternative when LD_LIBRARY_PATH only applies to one command, notice no semicolon below.
LD_LIBRARY_PATH=/path/to/the/shared/libs my_command
This article explains more.
I had tried adding:
export LD_LIBRARY_PATH=/path/to/the/shared/libs
which apparently works fine.
I was getting errors because my /path/to/the/shared/libs was incorrect.
Would still be good to know what others do for this and/if there is a better way.
If you want to set LD_LIBRARY_PATH for a particular make , try this LD_LIBRARY_PATH=/path/to/the/shared/libs make.
Adding this to the top of the Makefile worked for me:
export LD_LIBRARY_PATH := $(HOME)/lib
Pay attention not to add any extra spaces to the end of the line. I wasted some time until I realized that was the problem.
Related
This question already has an answer here:
Add compiler option without editing Makefile
(1 answer)
Closed 6 months ago.
Is there a way to suppress compiler warnings for GNU make and only show higher-order logs, i.e. errors?
Apparently, this should be possible using make -w as described here. However, for my version of GNU make (4.1), the man file specifies this as printing the current directory:
-w, --print-directory Print the current directory.
-W FILE
Consider FILE to be infinitely new.
If possible, this should be disabled both for make-internal warnings ($(warning ...)) and compiler-level warnings by gcc.
As pointed out in this post, it is not possible to directly add flags for the compiler. Furthermore, adding to existing CFLAGS variables (make CFLAGS+=-w) does not work either in most cases, as it ignores the append part and simply redefines the variable in the command line.
A very easy solution to fix this is by creating an empty dummy variable (once) inside your makefile and then defining it in case you need it:
# Add empty variable to add flags over command line
CDBG +=
CFLAGS += $(CDBG)
Which you then simply use as follows:
make CDBG=-w
as in https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
just add -w in your building command to suppress warnings, for example
gcc -Wall -w -o program pgmEcho.c pgm.c pgm.h
I would like to have a makefile like this:
cudaLib :
# Create shared library with nvcc
ocelotLib :
# Create shared library for gpuocelot
build-cuda : cudaLib
make build
build-ocelot : ocelotLib
make build
build :
# build and link with the shared library
I.e. the *Lib tasks create a library that runs cuda directly on the device, or on gpuocelot respectively.
For both build tasks I need to run the same build steps, only creating the library differs.
Is there an alternative to running make directly?
make build
Kind of a post-requisite?
Note: This answer focuses on the aspect of a robust recursive invocation of a different target in a given makefile.
To complement Jack Kelly's helpful answer, here's a GNU makefile snippet that demonstrates the use of $(MAKE) to robustly invoke a different target in the same makefile (ensuring that the same make binary is called, and that the same makefile is targeted):
# Determine this makefile's path.
# Be sure to place this BEFORE `include` directives, if any.
THIS_FILE := $(lastword $(MAKEFILE_LIST))
target:
#echo $# # print target name
#$(MAKE) -f $(THIS_FILE) other-target # invoke other target
other-target:
#echo $# # print target name
Output:
$ make target
target
other-target
Using $(lastword $(MAKEFILE_LIST)) and -f ... ensures that the $(MAKE) command uses the same makefile, even if that makefile was passed with an explicit path (-f ...) when make was originally invoked.
Note: While GNU make does have features for recursive invocations - for instance, variable $(MAKE) specifically exists to enable them - their focus is on invoking subordinate makefiles, not on calling a different target in the same makefile.
That said, even though the workaround above is somewhat cumbersome and obscure, it does use regular features and should be robust.
Here is the link to the manual section covering recursive invocations ("sub-makes"):
Recursive Use of make
Most versions of make set a variable $(MAKE) that you can use for recursive invocations.
As you have written it, the build target will need to do something different depending on whether you have just done an ocelot or cuda build. That's another way of saying you have to parameterise build in some way. I suggest separate build targets (much like you already have), with associated variables. Something like:
build-cuda: cudaLib
build-ocelot: ocelotLib
build-cuda build-ocelot:
shell commands
which invoke ${opts-$#}
On the command-line you type make build-cuda (say). Make first builds cudaLib, then it carries out the recipe for build-cuda. It expands the macros before calling the shell. $# in this case is build-cuda, thus ${opts-$#} is first expanded to ${opts-build-cuda}. Make now goes on to expand ${opts-build-cuda}. You will have defined opts-build-cuda (and of course its sister opts-build-ocelot) elsewhere in the makefile.
P.S. Since build-cuda et. al. are not real files, you had better tell make this (.PHONY: build-cuda).
I have a number of C/C++ project files. I'd like to know the full list of preprocessor symbols used by the files. Is there a flag to gcc, or is there some tool I can use to get this list.
Optionally, if the tool also told me the list of symbols defined by the file, that would be great.
Use gcc -E -dM <file_list> - preprocess, then output #defines.
My gcc is a tad rusty, so I'm not sure whether or not you explicitly need the -E, but try both?
For further reference, see this
When running a CMake generated Makefile with multiple processes (make -jN), the output often gets messed up like this:
[ 8%] [ 8%] [ 9%] Building CXX object App/CMakeFiles/App.dir/src/File1.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File2.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File3.cpp.o
I'm not sure, but I think this behavior is also there for Makefiles not generated by CMake. I'd say it happens when multiple processes write to stdout at the same time.
I know I'm probably being pedantic, but is there any (simple) fix to this? ;)
If you're using GNU make, you can do it by redefining SHELL such that commands are wrapped by a trivial utility that ensures atomicity of information printed to standard output. Here's a more detailed description, including sample source for the wrapper utility.
I tried to get the CMake people to fix this, but apparently they don't want to. See http://www.cmake.org/Bug/view.php?id=7062.
The specific CMake bug related to interleaved make output using -jN with N>1 is CMake bug 0012991: "Parallel build output mess". It is still open in the "backlog" state waiting to be fixed.
This bug is actually annoying enough that it's a strong reason to switch to Ninja instead of make. Plus the fact that Ninja is faster than make. Ninja also uses an appropriate number of parallel jobs based on the number of CPU cores present. Also cool is how Ninja is, by default, very quiet: all progress happens on a single line in the terminal unless the build process emits messages or a build step fails. If a build step fails, Ninja prints the full command line that invoked it and displays the output. It's really nice since it makes any warning or error messages stand out. Although currently there is no colored terminal output: that would be a nice improvement but for me the advantages of Ninja over make are tremendous.
Looks like it is already fixed. Add a -Oline parameter to the command line:
make -j 8 -Oline
Version of make:
GNU Make 4.3
Built for x86_64-pc-msys
Sun's (now Oracle's) dmake available on Linux and Solaris takes care of that.
See here and there.
Here is a simple working example of using a wrapper for Make. I'm not sure if I'd encourage it's use, but it's an idea.
# Makefile
SHELL = /tmp/test/wrapper
test: test1 test2
test1:
$(eval export TARGET=$#)
env
test2:
$(eval export TARGET=$#)
env
and this:
#!/usr/bin/env bash
# wrapper
bash $# | sed -e "s/^/${TARGET} /"
I use this tool called Lazy C++ which breaks a single C++ .lzz file into a .h and .cpp file. I want Makepp to expect both of these files to exist after my rule for building .lzz files, but I'm not sure how to put two targets into a single build line.
I've never used Makepp personally, but since it's a drop-in replacement for GNU Make, you should be able to do something like:
build: foo.h foo.cpp
g++ $(CFLAGS) foo.cpp -o $(LFLAGS) foo
foo.h foo.cpp: foo.lzz
lzz foo.lzz
Also not sure about the lzz invocation there, but that should help. You can read more about this at http://theory.uwinnipeg.ca/gnu/make/make_37.html.
Lzz is amazing! This is just what I was looking for http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c50de73b70a6a957/f3f47fcdcfb6bc09
Actually all you need is to depend (typically) on foo.o in your link rule, and a pattern rule to call lzz:
%.cpp %.h: %.lzz
lzz $(input)
The rest will fall into place automatically. When compiling any source that includes foo.h, or linking foo.o to a library or program, lzz will first get called automatically.
Makepp will also recognize if only the timestamp but not the content of the produced file changed, and ignore that. But it can't hurt to give it less to do, by using the lzz options to suppress recreating an identical file.
Regards -- Daniel