What files did `make install` copy, and where? - makefile

Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.

I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.

The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.

make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.

It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.

Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout

If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).

Related

Building Linux perf from source: how to modify the install directory?

I am following this wiki page to build perf from source as below:
PYTHON=python3 make -C tools/perf install
where ~/bin will be the default build directory.
How can I change the build directory to let's say ~/bin/test? I already have another perf build in ~/bin, and I want to have the new build in a different directory.
I have tried to modify the Makefile (if that is how to do it), but I could not figure it out.
One last silly question: Can I just move my current perf build to another directory or it will screw up its links?
You should be able to easily install into a different directory by specifying prefix=... or DESTDIR=... when running make. You will see this and other info if you run make -C tools/perf help:
$ make -C tools/perf help
...
Perf install targets:
NOTE: documentation build requires asciidoc, xmlto packages to be installed
HINT: use "prefix" or "DESTDIR" to install to a particular
path like "make prefix=/usr/local install install-doc"
install - install compiled binaries
...
Make sure to pass an absolute path to avoid problems (you can use realpath for that):
PYTHON=python3 make -C tools/perf prefix=$(realpath ~/bin/test) install

What makefile should I use to build a gtk-3-examples application?

I'm not really experienced with graphics programming, but I got curious. I installed both libgtk-3-dev and gtk-3-examples on my Debian 10.7 machine. From there I listed the example package files using dpkg-query -L gtk-3-examples to find some example programs.
In the examples directory I found the following README file:
== Building the examples ==
The examples in this directory are built alongside the rest of GTK+.
The examples under the `application[1-10]` directories are also included in
the GTK+ API reference documentation, and can be built independently, using
the system libraries, by doing:
$ cd application1
$ make -f Makefile.example
Looks straight forward. However, following the directions exactly yields the following result:
make: Makefile.example: No such file or directory
make: *** No rule to make target 'Makefile.example'. Stop.
There are no "Makefile.example" files in the application folders. Running find -name "Makefile*" in the examples directory yields:
./application7/Makefile.in.gz
./application7/Makefile.am
./Makefile.in.gz
./application5/Makefile.in.gz
./application5/Makefile.am
./bp/Makefile.in.gz
./bp/Makefile.am
./application9/Makefile.in.gz
./application9/Makefile.am
./application6/Makefile.in.gz
./application6/Makefile.am
./application2/Makefile.in.gz
./application2/Makefile.am
./application10/Makefile.in.gz
./application10/Makefile.am
./application3/Makefile.in.gz
./application3/Makefile.am
./application1/Makefile.in.gz
./application1/Makefile.am
./application8/Makefile.in.gz
./application8/Makefile.am
./application4/Makefile.in.gz
./application4/Makefile.am
./Makefile.am
I've not had any luck building an example program using the above files. I'm guessing it is because of my unfamiliarity with auto tools? Is there an easy way to build an example GTK program using the above files or do I need know a lot more about make/autotools/configure to get a working example running?
Update:
The cant-run-makefile-am-what-should-i-do post is informative but does not provide a course of action when no configure, bootstrap, or autogen programs can be found within the package. The following command yields no results when executed in my examples directory: find -type f | grep -i -E "*conf*|*auto*|*boot*". I need one of those files to be provided in order to have a successful build (as far as I understand it anyway).
Sorry for the fuss! I'm used to installing regular packages and missed that I needed to download the full source code to get the examples working. So, originally I mentioned that I installed both libgtk-3-dev and gtk-3-examples. I did so using apt-get install libgtk-3-dev && apt-get install gtk-3-examples.
However, to build GTK along with its examples locally it looks like what you want to do is get the source package archive with apt-get source gtk-3-examples (or similar.. I think it actually picked a different meta-package for me when I ran that command).
Then, in my new gtk+3.0-3.24.5 directory there's a nice configure binary that I can run (with subsequent make and make install commands) which produce many files including example program binaries.
So with ./gtk+3.0-3.24.5/examples/application1/exampleapp I get a running example. Voila!

configure command not found cygwin

This question has been asked many time but I am not able to resolve the problem from them so I am asking
I had installed Cygwin a few days ago.I tried using ./configure command but it says
-bash: ./configure: No such file or directory
I tried using
where configure
but I got the output
INFO: Could not find files for the given pattern(s).
then I tried grep configureand I got this output
/etc/bash_completion.d/configure
/usr/i686-pc-cygwin/sys-root/usr/share/libtool/libltdl/configure
/usr/share/ELFIO/configure
/usr/share/libtool/libltdl/configure
I tried to export the path and then run the ./configure but it also didn't worked.
I find no executable file named as configure in my cygwin bin directory.
Does it mean that I have to add configure file manually?How can I correct it?
NOTE :- I had also tried sh configure but it also didn't worked
If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.
So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
cd <sourcedir> # the one you just untarred
./configure
make
make install
Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).
Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install
So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.
If I correctly understood...
Configure is not an application that should be installed on your system, but script that should be delivered with source code to prepare for make command. File named configure should be in the main directory of source code.
I understand that this is an old question. However many might find this solution helpful.
Normally we use the make command to compile a downloaded source in cygwin. In many cases it contains a autogen.sh file. Running that file with
bash autogen.sh
will in many case solve the problem. At least it solved my issue and i could then use the make command

Building debian package for shell script

What: I've a shell script that I'd like to distribute to my LUG.
I believe that a debian package will be the easiest way to distribute it. I want to create a .deb file for the script in this repository
Where: I want it to be placed in some directory like /usr/local/bin so that it is easy to execute and maybe create some symbolic links
Problem: How to write make file for it and/or other files and folders required to do that. I researched a lot when I tried to do it couple of months ago but no luck then. Here are the files from my previous attempt Now I'm trying to pack this for a tutorial on shell script in my LUG and facing similar situation again.
I'll be really glad if someone can be patient enough to guide me through it.
Any kind of resources or details will be much appreciated.
PS: I also intend to port the script to perl soon.
As mirabilos said, you should at least have a look to the packaging-tutorial written by Lucas Nussbaum, the current Debian Project Leader. You can install it directly from a Debian repository:
# apt-get install packaging-tutorial
Then, open and skim the PDF located at /usr/share/doc/packaging-tutorial/packaging-tutorial.pdf. After skimming it you'll have the basic knowledge needed to understand the structure of a Debian package.
Now let's get our hands dirty. mv your script to a new directory. The name of the directory must follow the nomenclature upstreamname-*version*.
rul#helicon:/tmp/a$ mkdir script-0.1
rul#helicon:/tmp/a$ mv script.sh script-0.1
cd to the directory where your script is and run dh_make --createorig. Choose single binary. You'll now have a debian/ directory with lots of file in it. This files are the ones you need to make your package. In your case, most, if not all, of the *.ex files are safe to be removed. Read and modify when needed the remaining files.
Now let's write the core of our package. You want to install a script in /usr/local/bin. The good news is that there is already a program that does that for you. You just have to specify the file name and where to put it. This program is dh_install. It has a very complete man page. After reading it, you should now understand that you have to create a install file in the debian/ directory.
rul#helicon:/tmp/a/script-0.1$ echo "script.sh usr/local/bin/" > debian/install
Here you have a real example of this file usage.
That's it! You have all you need to build your package. cd to the root directory of your package and run dpkg-buildpackage. If all went well, you'll have your fresh new .deb in ../.
You really should have a look at, in this order, the inofficial packaging tutorial, the Debian New Maintainers' Guide, Debian Developer's Reference and Policy. (The order is also increasingly dry, and reversed for formalness.)
It may take two days or so, but is really worth it.
Also, look at other small packages shipping only scripts, or other mere “file installers” (like php-htmlpurifier, first example I remembered while writing this).
If your package will only have a single file (or small number of files) in it, going through the full Debian toolchain might be overkill.
For packaging single files, I recommend you use the equivs tool. Install the equivs package, then run equivs-control to create a template file.
Edit the template file (give your package a name, version number etc.).
Add the name of your script to the Files: attribute in the template, for example:
Package: my-awesome-script
Version: 4.2
Files: my-awesome-script.sh /usr/local/bin
Section: misc
Priority: optional
Standards-Version: 3.9.2
Maintainer: Me <me#gmail.com>
Description: An awesome script doing stuff
Lorem ipsum etc. pp.
Put the script file alongside the template file.
Run equivs-build which will create your Debian package.
This is much easier for these simple cases than anything else – and the package that you get is standards compliant without resorting to any hacks or jumping through hoops.
for pre install, write your script in file DEBAIN/preinst;
for post install, write your script in file DEBAIN/postinst;
Use checkinstall or fpm to build your packages in minutes not hours or days!:
sudo checkinstall --fstrans=yes --install=no -D --pkgname=script \
--maintainer='Name <name#domain.tld>' --pkgarch=all --pkgversion=0.1 \
--nodoc cp script.sh /usr/local/bin
fpm -s dir -t deb --prefix /usr/local/bin -n script -v 0.1 -a all ./script.sh
Note: checkinstall requires dpkg/dpkg-deb (only works on Debian/Ubuntu), fpm is platform independent but requires ruby.

What does /usr/sbin/install really do?

I'm trying to install discount on my VPS which is based on Solaris and compiling works great after setting some environment variables but the install fails.
So I thought I'd do the install manually, but what does install really do? Is it simply a mv followed by a chmod? Is it magic? That error seems to show that it attempts to do a lot of searching for files all over?
Can I just copy the binary, library and header files as usual?
Googling "install" doesn't give me much relevant information so I appreciate any clarification I can get!
According to man install:
install [OPTION]... [-T] SOURCE DEST`
install [OPTION]... SOURCE... DIRECTORY
install [OPTION]... -t DIRECTORY SOURCE...
install [OPTION]... -d DIRECTORY...
In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to
the existing DIRECTORY, while setting permission modes and owner/group.
In the 4th form, create all components of the given DIRECTORY(ies).
As for the difference to using cp, according to install vs. cp; and mmap, install unlinks the existing file, creating a new one linked to the same spot.
This has the advantage that, if the file you're trying to overwrite is a currently running program, it can continue running, as the file being written is in fact in a new location, and the existing program code is still in the old one.
A cp simply tries to overwrite the existing file, which will fail if the file is locked due to being in use.
Further information
install Command

Resources