I am trying to include some dynamic libraries (.so files) for a simple 3D game I am making on linux using C++. These dynamic libraries are for using the Bullet physics engine.
I have very limited knowledge of how use automake and autoconf so any help would be much appreciated.
How might I modify any of the following files to include these dynamic libraries?
Here is my makefile.am:
noinst_HEADERS= BaseApplication.h Physics.h GameApplication.h
bin_PROGRAMS= OgreApp
OgreApp_CPPFLAGS= -I$(top_srcdir)
OgreApp_SOURCES= BaseApplication.cpp Physics.cpp GameApplication.cpp
OgreApp_CXXFLAGS= $(OGRE_CFLAGS) $(OIS_CFLAGS)
OgreApp_LDADD= $(OGRE_LIBS) $(OIS_LIBS)
EXTRA_DIST = buildit makeit
AUTOMAKE_OPTIONS = foreign
Here is my configure.ac:
AC_INIT(configure.ac)
AM_INIT_AUTOMAKE(SampleApp, 0.1)
AM_CONFIG_HEADER(config.h)
AC_LANG_CPLUSPLUS
AC_PROG_CXX
AM_PROG_LIBTOOL
PKG_CHECK_MODULES(OGRE, [OGRE >= 1.2])
AC_SUBST(OGRE_CFLAGS)
AC_SUBST(OGRE_LIBS)
PKG_CHECK_MODULES(OIS, [OIS >= 1.0])
AC_SUBST(OIS_CFLAGS)
AC_SUBST(OIS_LIBS)
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
I also have a buildit file that sets everything in motion:
#!/bin/sh
rm -rf autom4te.cache
libtoolize --force --copy && aclocal && autoheader && automake --add-missing --force-missing --copy --foreign && autoconf
./configure && ./makeit
For Bullet, there should be a bullet.pc file installed on your system which you can use with the autocong macro PKG_CHECK_MODULES, the same way OGRE and OIS are included:
# in configure.ac
PKG_CHECK_MODULES(BULLET, [bullet])
# in Makefile.am
OgreApp_CXXFLAGS= $(OGRE_CFLAGS) $(OIS_CFLAGS) $(BULLET_CFLAGS)
OgreApp_LDADD= $(OGRE_LIBS) $(OIS_LIBS) $(BULLET_LIBS)
If you add more unconditional dependencies, you might want to simplify both files by grouping them like this:
# in configure.ac
PKG_CHECK_MODULES(DEPENDENCIES, [OGRE >= 1.2 OIS >= 1.0 bullet])
# in Makefile.am
OgreApp_CXXFLAGS= $(DEPENDENCIES_CFLAGS)
OgreApp_LDADD= $(DEPENDENCIES_LIBS)
And as Jack Kelly wrote in the comments, if you have pkg-config >= 0.24 (released in 2010), you don't need to use AC_SUBST after PKG_CHECK_MODULE.
In your Makefile.am:
OgreApp_LIBADD= -llib1 -llib2
Does that help?
Edit: or try appending -llib1 -llib2 to the OgreApp_LDADD=... line, I'm not sure myself.
Related
"ar" -- is just tool to create archives.
And all static libraries of form "lib*.a" are in fact just archived compiled objects + additional file with symbol table, added there by "ranlib".
No linking is performing during creation of such library.
So why do most of projects use ***_LDFLAGS ***_LIBADD in their Makefile.am during creation of such ("lib*.a" static library) archives?
Does automake ignore those flags (in case when they relate to any "lib*.a" static library), or does it in fact link something there?
So why do most of projects use ***_LDFLAGS ***_LIBADD in their Makefile.am during creation of such ("lib*.a" static library) archives?
The GNU Build System is capable of creating dynamic and static libs (or both) determined at configure time using the --enable-shared and --enable-static flags. As you guessed, _LDFLAGS and _LIBADD are more oriented to dynamic shared objects or program linkage than to the static linker. The static linker of libtool is essentially another link pass that invokes ar to create the archive (omitting all the flags). For example:
lib_LTLIBRARIES=libfoo.la
libfoo_la_SOURCES=$(SRCS)
libfoo_la_LDFLAGS=-Wl,-t
when both shared and static libs are generated outputs something like:
libtool: link: gcc -shared -fPIC -DPIC .libs/foo.o -g -O2 -Wl,-t -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
...
libtool: link: (cd ".libs" && rm -f "libfoo.so.0" && ln -s "libfoo.so.0.0.0" "libfoo.so.0")
libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s "libfoo.so.0.0.0" "libfoo.so")
libtool: link: ar cru .libs/libfoo.a foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )
automake does ignore _LDFLAGS; however the script that performs the linking (libtool) does not. It looks for flags that affect linking there also. For example:
lib_LTLIBRARIES=libfoo.la
libfoo_la_SOURCES=$(SRCS)
libfoo_la_LDFLAGS=-Wl,-t -static
will only generate a static lib, even if configure --disable-static was run to generate the Makefile.
libtool is just a wrapper script over the native compiler/linker tools for portability.
Answer to your question Does automake ignore them is: NO
That is completely true: ""ar" -- is just tool to create archives."
But, Automake does not ignore ***_LDFLAGS ***_LIBADD in their Makefile.am at all, otherwise what is point of having such flag if they are not making any sense for the build system!
From documentation (link give below):
The ‘library_LIBADD’ variable should be used to list extra libtool objects (.lo files) or libtool libraries (.la) to add to library.
The ‘library_LDFLAGS’ variable is the place to list additional libtool linking flags, such as -version-info, -static, and a lot more.
For more details, you should go through this Libtool Documentation for more clarity in these flags.
8.3.7 _LIBADD, _LDFLAGS, and _LIBTOOLFLAGS
Libtool Documentation
EDIT:
As your question is still generic, let me put it in two different scenario...
Static Lib is stand-alone:
In this scenario ***_LIBADD could be not much useful, as mentioned in documentation: "the library_LIBADD variable should be used to list extra libtool objects (.lo files) or libtool libraries (.la) to add to library"
Which means, if your static lib does not have dependency then this flag is no of use in it's Makefile.am.
Static Lib is Dependent (not stand-alone)
From above quote from documentation, it is now clear that, ***_LIBADD flag is used to mentioned libs names which are required to build your current library.
So this flag would be necessary in such requirement.
And about ***_LDFLAGS, as mentioned in documentation, The library_LDFLAGS variable is the place to list additional libtool linking flags for that library.
If your lib does not require such flags, then this can be ignored too. It is all about how you want your final result.
Few more additional links for your reference:
LDFLAGS usage in autotools with libtool
What is the difference between LDADD and LIBADD?
I hope this EDIT suffices what you're looking for.
PS: If you would read my answer carefully and went through documentation, you could have get the same data. Njoy. :)
From entire day I am trying to install OverSim [http://www.oversim.org/wiki/OverSimInstall]
The make file looks like this:
all: checkmakefiles
cd src && $(MAKE)
clean: checkmakefiles
cd src && $(MAKE) clean
cleanall: checkmakefiles
cd src && $(MAKE) MODE=release clean
cd src && $(MAKE) MODE=debug clean
rm -f src/Makefile
makefiles:
cd src && opp_makemake -f --deep --make-so -o inet -O out $$NSC_VERSION_DEF
checkmakefiles:
#if [ ! -f src/Makefile ]; then \
echo; \
echo '======================================================================='; \
echo 'src/Makefile does not exist. Please use "make makefiles" to generate it!'; \
echo '======================================================================='; \
echo; \
exit 1; \
fi
doxy:
doxygen doxy.cfg
tcptut:
cd doc/src/tcp && $(MAKE)
I am using Omnet5.1.1 as omnet4.2.2 is not supported on Ubuntu16.04, my gcc version is 5.4.1.
Every time I try to build this make all, it gives header file not found error where as in actual the header files are present inside the project directory.
In file included from applications/ethernet/EtherAppCli.cc:21:0:
applications/ethernet/EtherAppCli.h:21:22: fatal error: INETDefs.h: No such file or directory
The includes are done like this:
#include "INETDefs.h" //available at src/linklayer/contract/
#include "MACAddress.h" //available at src/base/
project structure:
How could I resolve this build error?
This is a basic difference between newer OMNeT++ versions 5.x and the older OMNeT++ versions 3.x and 4.x.
As far as I remember Oversim, it was released for build with OMNeT 3.x and 4.2 as well as the older INET releases.
These old versions used parameters like --deep to search for include files, that's why the included files are just named and not entered with a complete path.
The newer INET and OMNeT releases use hierarchical path settings for include files. The complete paths have to be given for the compiler to access the included file.
So for INET version 3.x and OMNeT++ version 5.x, an include looks like: #include "inet/common/INETDefs.h"
Oversim does not include the complete paths for included headers, that's why you have errors when using Oversim with newer OMNeT releases.
The first option is to either use an older OMNeT version. Either install an older GCC in parallel on your system or set-up a virtual machine with an older Ubuntu if you like.
The second (and more complex) option is to adopt all include paths or define all necessary paths via the -I option of the compiler/linker.
Frankly, I'd suggest to use the older OMNeT++ 4.2.2 version...
The #include directive searches first of all inside the same directory as the file containing the directive and then in a preconfigured list of standard system directories.
If you don't want to move the header files to the same directory as EtherAppCli.cc, you will have to add the paths to these header files to this preconfigured list, usually with the compiler option
-Ipath/to/dir
I'm not sure if this is what is intended in the app your'e compiling but this is more or less what you can do.
Check to see if you missed anything in the installation guide.
Use OMNet 4.6 instead. Keep using inet-20111118. You should be able to build inet normally. Then build Oversim
I've made a program in C++, but now I must install this program with autoconf and automake.
So, when I run command "./configure && make && make install", it must do the following:
compile program
create folder my_program inside /opt (example: /opt/my_program/) and in this folder I must also have all static libraries and source files
There must be symbolic link in /usr/local/bin for my_program
Libraries must be in /usr/local/lib (DONE - Thanks to #Galik )
Header files of my_program must be in /usr/local/include (DONE)
I've wrote this configure.ac script:
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.69])
AC_INIT([my_program], [0.1], [my_mail])
AC_CONFIG_SRCDIR([AbsAlgorithm.hpp])
AM_INIT_AUTOMAKE
# Checks for programs.
AC_PROG_CXX
AC_PROG_CC
# Checks for libraries.
# Checks for header files.
AC_CHECK_HEADERS([stdlib.h string.h sys/time.h unistd.h wchar.h wctype.h])
# Checks for typedefs, structures, and compiler characteristics.
AC_CHECK_HEADER_STDBOOL
AC_C_INLINE
AC_TYPE_SIZE_T
# Checks for library functions.
AC_FUNC_MALLOC
AC_FUNC_MKTIME
AC_CHECK_FUNCS([gettimeofday memset mkdir])
LIBS="-ldl"
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
and this Makefile.am script:
AUTOMAKE_OPTIONS = foreign
AM_CXXFLAGS=-Wall -std=gnu++11 -DVERSION=\"$(VERSION)\" -DPROG="\"$(PACKAGE)\""
bin_PROGRAMS = algatorc
noinst_LIBRARIES = libalgatorc.a
libalgatorc_a_SOURCES = Timer.cpp
include_HEADERS = Timer.hpp TestSetIterator.hpp TestCase.hpp ETestSet.hpp EParameter.hpp Entity.hpp ParameterSet.hpp AbsAlgorithm.hpp Log.hpp JSON.hpp
algatorc_SOURCES = ParameterSet.cpp TestCase.cpp EParameter.cpp ETestSet.cpp TestSetIterator.cpp Entity.cpp Timer.cpp main.cpp JSON.cpp JSONValue.cpp
Now, when I run "./configure && make && make install" I don't get new folder called my_program in /opt. But, I now, I do have header files in /usr/local/include. I don't have lib files in /usr/local/lib. There is just one folder for python. I would like to have folder called my_program and inside that folder I would like to have static libs.
I am using Ubuntu 12.04 x64
I would appreciate any help. Thanks
Autotools is not really designed to put things in specific locations. The idea is that programs go in the programs directory $(bindir), libraries in the libraries directory $(libdir) etc and that the person installing everything gets to decide where those locations are.
So you should really only care about installing things relative to wherever the person running the installer wants them to be.
They do this by adding arguments to the configure script like:
configure --prefix=/opt/myprog
That will typically install programs in /opt/myprog/bin and libraries in /opt/myprog/lib etc...
You can add to the places that things get installed by setting special dir variables. For example to put libraries in a sub-directory of $(libdir) (default /usr/local/lib) you caan do:
myprog_librarydir = $(libdir)/myprog
And its not uncommon to do the same for the header files:
myprog_includedir = $(prefix)/include/myprog
That defines some destination folders you can refer to instead of the defaults:
myprog_include_HEADERS = \
Timer.hpp \
TestSetIterator.hpp \
TestCase.hpp \
ETestSet.hpp \
EParameter.hpp \
Entity.hpp \
ParameterSet.hpp \
AbsAlgorithm.hpp \
Log.hpp \
JSON.hpp
Those will now get installed into $(prefix)/include/myprog.
Similarly with the corresponding library:
myprog_library_LIBRARIES = libmyprog.a
libmyprog_a_SOURCES = \
ParameterSet.cpp \
TestCase.cpp \
EParameter.cpp \
ETestSet.cpp \
TestSetIterator.cpp \
Entity.cpp \
Timer.cpp \
JSON.cpp \
JSONValue.cpp
So basically you create a destination (installation) directory using:
mynamedir = $(prefix)/path/... whatever
That allows you to set destinations other than bin_, lib_ and include_ etc...
So instead of saying lib_LIBRARIES you can say myname_LIBRARIES.
Hope that helps.
I am trying to build gcc 4.7.2 using a custom prefix $PREFIX
I have built and installed all the prerequisites into my prefix location, and then successfully configured, built and installed gcc.
The problem that I now have is that $PREFIX is not in the library search path, and therefore the shared libraries cannot be found.
$PREFIX/bin $ ./g++ ~/main.cpp
$PREFIX/libexec/gcc/x86_64-suse-linux/4.7.2/cc1plus: \
error while loading shared libraries: \
libcloog-isl.so.1: \
cannot open shared object file: No such file or directory
What works, but isn't ideal
If I export LD_LIBRARY_PATH=$PREFIX/lib then it works, but I'm looking for something which works without having to set environment variables.
If I use patchelf to set the RPATH on all the gcc binaries then it also works; however this involves searching out all elf binaries and iterating over them calling patchelf, I would rather have something more permanent.
What I think would be ideal for my purposes
So I'm hoping there is a way to have -Wl,-rpath,$PREFIX/lib passed to make during the build process.
Since I know the paths won't need to be changed this seems like the most robust solution, and can be also be used for when we build the next gcc version.
Is configuring the build process to hard code the RPATH possible?
What I have tried, but doesn't work
Setting LDFLAGS_FOR_TARGET prior to calling configure:
All of these fail:
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -R$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
Setting LDFLAGS prior to calling configure:
export LDFLAGS="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
In any event I worry that these will override any of the LDFLAGS gcc would have had, so I'm not sure these are a viable option even if they could be made to work?
My configure line
For completeness here is the line I pass to configure:
./configure \
--prefix=$PREFIX \
--build=x86_64-suse-linux \
--with-pkgversion='SIG build 12/10/2012' \
--disable-multilib \
--enable-cloog-backend=isl \
--with-mpc=$PREFIX \
--with-mpfr=$PREFIX \
--with-gmp=$PREFIX \
--with-cloog=$PREFIX \
--with-ppl=$PREFIX \
--with-gxx-include-dir=$PREFIX/include/c++/4.7.2
I've found that copying the source directories for gmp, mpfr, mpc, isl, cloog, etc. into the top level gcc source directory (or using symbolic links with the same name) works everywhere. This is in fact the preferred way.
You need to copy (or link) to those source directory names without the version numbers for this to work.
The compilers do not need LD_LIBRARY_PATH (although running applications built with the compilers will need an LD_LIBRARY_PATH to the $PREFIX/lib64 or something like that - but that's different)
Start in a source directory where you'll keep all your sources.
In this source directory you have your gcc directory either by unpacking a tarball or svn...
I use subversion.
Also in this top level directory you have, say, the following source tarballs:
gmp-5.1.0.tar.bz2
mpfr-3.1.1.tar.bz2
mpc-1.0.1.tar.gz
isl-0.11.1.tar.bz2
cloog-0.18.0.tar.gz
I just download these and update to the latest tarballs periodically.
In script form:
# Either:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_work
# Or:
bunzip -c gcc-4.8.0.tar.bz2 | tar -xvf -
mv gcc-4.8.0 gcc_work
# Uncompress sources.. (This will produce version numbered directories).
bunzip -c gmp-5.1.0.tar.bz2 | tar -xvf -
bunzip -c mpfr-3.1.1.tar.bz2 | tar -xvf -
gunzip -c mpc-1.0.1.tar.gz | tar -xvf -
bunzip -c isl-0.11.1.tar.bz2 | tar -xvf -
gunzip -c cloog-0.18.0.tar.gz | tar -xvf -
# Link outside source directories into the top level gcc directory.
cd gcc_work
ln -s ../gmp-5.1.0 gmp
ln -s ../mpfr-3.1.1 mpfr
ln -s ../mpc-1.0.1 mpc
ln -s ../isl-0.11.1 isl
ln -s ../cloog-0.18.0 cloog
# Get out of the gcc working directory and create a build directory. I call mine obj_work.
# I configure the gcc binary and other outputs to be bin_work in the top level directory. Your choice. But I have this:
# home/ed/projects
# home/ed/projects/gcc_work
# home/ed/projects/obj_work
# home/ed/projects/bin_work
# home/ed/projects/gmp-5.1.0
# home/ed/projects/mpfr-3.1.1
# home/ed/projects/mpc-1.0.1
# home/ed/projects/isl-0.11.1
# home/ed/projects/cloog-0.18.0
mkdir obj_work
cd obj_work
../gcc_work/configure --prefix=../bin_work <other options>
# Your <other options> shouldn't need to involve anything about gmp, mpfr, mpc, isl, cloog.
# The gcc build system will find the directories you linked,
# then configure and compile the needed libraries with the necessary flags and such.
# Good luck.
I've been using this configure option with gcc-4.8.0, on FreeBSD, after building and installing gmp, isl and cloog:
LD_LIBRARY_PATH=/path/to/isl/lib ./configure (lots of other options) \
--with-stage1-ldflags="-rpath /path/to/isl/lib -rpath /path/to/cloog/lib -rpath /path/to/gmp/lib"
and the resulting gcc binary does not need any LD_LIBRARY_PATH. The LD_LIBRARY_PATH for configure is needed because it compiles a test program to check for the ISL version, which would fail if it didn't find the ISL shared lib.
I tried it on Linux (Ubuntu) where it failed during configuring because the -rpath args were passed to gcc instead of ld. I could fix this by using
--with-stage1-ldflags="-Wl,-rpath,/path/to/isl/lib,-rpath,/path/to/cloog/lib,-rpath,/path/to/gmp/lib"
instead.
Just using configure --with-stage1-ldflags="-Wl,-rpath,/path/to/lib" was not enough for me to build gcc 4.9.2, bootstrap failed in stage 2. What works is to pass he flags directly to make via
make BOOT_LDFLAGS="-Wl,-rpath,/path/to/lib"
I got this from https://gcc.gnu.org/ml/gcc/2008-09/msg00214.html
While it still involves setting environment variables, what I do is that I define LD_RUN_PATH, which sets the rpath. That way the rest of the system can keep using the system provided libraries instead of using the ones that your gcc build generates.
I am going to make a suggestion that I believe solves your problem, although it definitely does not answer your question. Let's see how many downvotes I get.
Writing a generic wrapper script to set LD_LIBRARY_PATH and then to run the executable is easy; see https://stackoverflow.com/a/7101577/768469.
The idea is to pass something like --prefix=$PREFIX/install to configure, building an install tree that looks like this:
$PREFIX/
install/
lib/
libcloogXX.so
libgmpYY.so
...
bin/
gcc
emacs
...
bin/
.wrapper
gcc -> .wrapper
emacs -> .wrapper
.wrapper is a simple shell script:
#!/bin/sh
here="${0%/*}" # or use $(dirname "$0")
base="${0##*/}" # or use $(basename "$0")
libdir="$here"/../install/lib
if [ "$LD_LIBRARY_PATH"x = x ] ; then
LD_LIBRARY_PATH="$libdir"
else
LD_LIBRARY_PATH="$libdir":"$LD_LIBRARY_PATH"
fi
export LD_LIBRARY_PATH
exec "$here"/../install/bin/"$base" "$#"
This will forward all arguments correctly, handle spaces in arguments or directory names, and so forth. For practical purposes, it is indistinguishable from setting the rpath like you want.
Also, you can use this approach not only for gcc, but for your entire my-personal-$PREFIX tree. I do this all the time in environments where I want an up-to-date suite of GNU tools, but I do not have (or want to admit to have) root access.
Try to add your $PREFIX to /etc/ld.so.conf and then run ldconfig:
# echo $PREFIX >> /etc/ld.so.conf
# ldconfig
This will recreate cache that is used by runtime linker and it will pick up your libraries.
WARNING: This operation will cause ALL applications to use your newly compiled libraries in $PREFIX instead of default location
Being perfectly satisfied with old-style Makefiles, I am looking for a simple alternative to libtool. I do not want to switch to automake, and I keep running into problems with libtool when I try to use it directly. The latest one is 'unsupported hardcode properties', and I am getting fed up with the lack of complete documentation that just tells me what is wrong this time...
I only want to compile a bunch of .o files with the right flags and then link them into a shared library, such that it works on as many platforms as possible. Is there anything out there that does just that and not force me to switch all of my other tools at the same time?
I not sure if it would fit info your workflow but I'd recommend looking at CMake. It works on Windows, Linux and Mac and should not force you to change any of your other tools. You'll have to judge its suitability yourself though.
There's jlibtool (which has nothing to do with java).
It's written in C, and can just be bundled with your source.
It was originally an apache project, but whoever was working it there seems to of abandoned it around 2004.
It was taken over by FreeRADIUS project maintainer Alan Dekok, who modernised the code and fixed a few niggling issues. We use it for the FreeRADIUS project (>= 3.0.0) to do all the build time linking.
Given your description in the comment to Milliams' answer,
I just want one tool that I tell: "give me the compiler flags so that I can compile these n files for use in a shared library, and then give me the commands to link them together",
then libtool may well be the simplest tool for the job. I know of no other alternative.
You are right that the documentation for using libtool with plain makefiles is practically nonexistent, but libtool certainly does not require you to switch to automake. Cross-platform libraries are difficult, and the price you have to pay for them is libtool. (Or maybe the discount price is libtool+automake+autoconf or CMake or Jam.)
slibtool (dl.midipix.org/slibtool, git://midipix.org/slibtool) is a libtool drop-in replacement, written in C. A single slibtool binary aims to seamlessly support both native and cross-builds, and the utility also provides some additional features (installation of .la files is optional, optional color-coded annotation, etc). The following minimal plain makefile demonstrates how to (cross-) build a library using slibtool.
CC = cc
LIBTOOL = slibtool
DESTDIR = destdir
all: libfoo.la
a.lo:
$(LIBTOOL) --mode=compile --tag=CC $(CC) -c a.c
libfoo.la: a.lo
$(LIBTOOL) --mode=link --tag=CC $(CC) -o libfoo.la -rpath /lib
install: all
mkdir -p destdir
$(LIBTOOL) --mode=install cp libfoo.la $(DESTDIR)
# the -rpath argument is required for semantic compatibility with libtool.
native build, default (both shared library and static library)
$ make
$ make install
native build, shared library only
$ make LIBTOOL=slibtool-shared
$ make install
native build, static library only
$ make LIBTOOL=slibtool-static
$ make install
cross-build, default
$ make CC=some-target-tuple-gcc
$ make install
cross-build, default, with lots of colors
$ make LIBTOOL=dlibtool CC=some-target-tuple-gcc
$ make install