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
Related
I hit this error message while trying to build gnote using GNU Autotools.
I had first run:
$ git clean -xf # to clean the tree of untracked files, then
$ autoreconf # to create the script named `configure`, and finally
$ ./configure # to check my system, and create Makefiles from their templates
Neither po/Makefile.in.in nor po/Makefile.in exist in the source tree that I downloaded.
Yet configure needs to make this po/Makefile, as called for in the root Makefile.am in this line:
SUBDIRS = data src po help
Where do I get, or how do I make, po/Makefile.in.in?
Like all Gnome related packages, gnote uses many steps of buildsystem setup beyond just running autoreconf.
The autogen.sh script gnote comes with should run all the required steps to set up the buildsystem.
As usual, run the autogen.sh script with the --help parameter if you want to call configure separately.
po/Makefile.in.in is created by running intltoolize from the intltool package. It needs to be run from the project tree's root directory.
There isn't much documentation on intltoolize that I could find except for the brief man page, but it's source code says that that it's a fork of an older utility called libtoolize, and it's a relatively short script.
(BTW, if you don't already have intltoolize installed, you can figure out which package installs it, with this: sudo apt-file find intltoolize.)
*.in files are templates used by AutoMake to create a Makefile.
.in.in is a soft link to /usr/share/intltool/Makefile.in.in.
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
I've downloaded tar.gz files from official site(versions 2.4.3, 2.4.7, 2.4.8). Then unzipped them somewhere.
mac-mini-olia:Data olia$ cd opencv-2.4.6.1/
mac-mini-olia:opencv-2.4.6.1 olia$ mkdir build
mac-mini-olia:opencv-2.4.6.1 olia$ cd build/
mac-mini-olia:build olia$ cmake -G "Unix Makefiles" ..
mac-mini-olia:build olia$ make -j8
after the last command output is
3910 warnings and 12 errors generated.
Errors are like
/Volumes/Data/opencv-2.4.6.1/3rdparty/libjpeg/._jcapimin.c:1:4096: error: source file is not valid UTF-8
and
/Volumes/Data/opencv-2.4.6.1/3rdparty/libpng/._pngerror.c:1:2: error: expected identifier or '('
And after that in /usr/local/lib and /usr/local/include there are no files of opencv.
There are multiple ways to install OpenCV on OSX.
You can use MacPorts
Make sure you have XCode installed with it's Command Line Tools first.
(An easy way to test that is to see if xcodebuild if a found command in Terminal)
After you install MacPorts simply do
sudo port install opencv
This will take care of building the project from source and installing it for you.
(The path might be /opt/local/lib /opt/local/include though, haven't used it in a while)
There are also port variants: opencv with options. For example if you plan to use openni 1.5.x and have it integrated with opencv you can try
sudo port install opencv +openni
If you do
sudo port variants opencv
you should get a list of all the options(e.g. python support, qt support, etc.)
If you want to build from source yourself, I recommend installing the ccmake command (I think macports can also do that for you) or use the CMake gui tool. This will allow you to easily configure the build and setup your install location(/use/local/...and so on)
So you can try someting like this:
cd /path/to/your/opencv_folder
mkdir build && cd build
ccmake ..
At this stage you should see something like this:
hit Enter to change an option and Enter again to exit edit mode and use the up/down keys to scroll through the options. When you're happy with the settings, press C to configure. Once that's done, you can press G to generate. This will generate the makefiles for you so you can do this:
make
sudo make install
make install will actually copy the built libraries/headers to the /usr/ folder.
You might run into errors when running make, depending on your setup(e.g. if you're missing dependencies, etc.), but the cool thing about ccmake is that you can go back, run it again, disable the things you don't want to build right now and go back to the make stage.
I have been trying to install numba in a virtual environment. Numba requires llvm and what seems to be a Python wrapper of llvmpy. I successfully installed it using the following steps:
wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
tar zxvf llvm-3.2.src.tar.gz
cd llvm-3.2.src
./configure --enable-optimized --prefix=/opt
REQUIRES_RTTI=1 make
make check-all
sudo REQUIRES_RTTI=1 make install
git clone git://github.com/llvmpy/llvmpy.git
cd llvmpy
sudo LLVM_CONFIG_PATH=/opt/bin/llvm-config /path/to/environment/bin/python setup.py install
python -c "import llvm; llvm.test()"
However, I would like to know what is the correct procedure. For example, in the line REQUIRES_RTTI=1 make and sudo REQUIRES_RTTI=1 make install, the variable REQUIRES_RTTI is repeated. Is it necessary?
According to the documentation of numba, it recommends to execute REQUIRES_RTTI=1 make install and llvmpy recommends REQUIRES_RTTI=1 make, so there are slight differences. I don't really know what each step is doing so I would appreciate a general explanation of what is going on and if all these steps are strictly necessary.
Furthermore, what is make check-all? I have seen it is particularly relevant in questions related to llvm but I don't know what is its purpose.
Another suggestion from llvmpy's documentation is to install using a different directory (--prefix) Why is that the recommended approach?
Thanks a lot
The following lines
REQUIRES_RTTI=1 make
sudo REQUIRES_RTTI=1 make install
use the way of setting up environment of the called process without modifying the environment of the calee (like in case of export REQUIRES_RTTI=1); from bash manual:
The environment for any simple command or function may be augmented
temporarily by prefixing it with parameter assignments. These assignment statements affect only the
environment seen by that command.
This setting is recommended because from LLVM docs:
Add REQUIRES_RTTI=1 to your environment
while running make to re-enable it. This will allow users to build
with RTTI enabled and still inherit from LLVM classes.
and according to llvmpy docs, RTTI is required.
So, forgetting this "complication" and standard requirement to use "sudo" for installing, the steps are standard:
### generating makefile:
./configure --enable-optimized --prefix=/opt
### building core libraries (make without target is the same as "make all")
make
### check-all is a makefile target that is used to run regression tests (according to LLVM docs)
make check-all
### installing the libraries to the place where other tools / libraries can find them:
make install
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).