I want to compile and run a specific version of a FreeBSD utility from the source code.
For example, I downloaded the repo for the following utility: https://svnweb.freebsd.org/base/stable/9/sbin/routed/
However, when I run the make command, I get the following error:
"../Makefile.inc", line 3: Cannot open ../Makefile.inc
make: fatal errors encountered -- cannot continue
*** [all] Error code 1
Can someone point me in the right direction?
You will need to download the whole source tree. The build system depends on pieces from different locations in the tree. Then;
Unpack the source in /usr/src
cd /usr/src/sbin/routed
make && make install
It looks like you want the 9-stable branch? If you have subversion available, you can do:
rm -rf /usr/src/
svn co svn://svn.freebsd.org/base/stable/9 /usr/src
(Depending on your FreeBSD version, svn may also be called svnlite) Also see the handbook.
On my machine, the complete /usr/src tree is 2445 MiB, including the .svn directory.
Edit: Note that it a program relies on system calls, library functions or other features that were introduced in a certain branch/version of FreeBSD, it will not work on older branches/versions.
Related
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!
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.
I'm working on several supercomputers, which have different autotools versions.
When I do make after ./configure, some of them give me an error about wrong version of aclocal.
If I re-configure my configure.ac on one platform, then same thing happens on the other one.
For example, one platform would give me this:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.15
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
If I run autoreconf, it would work fine on it. However, if I use that newly generated configure.ac on some other platforms, they will give me the same error with different version number:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.13
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
I know I can just run autoreconf -fi every time I go to a different platform, but I heard it isn't a good practice to make end users to do it as it requires them to install autotools.
They have three different versions, and I don't know how to handle this. Is there any ways to automatically run autoreconf when I run ./configure to regenerate configure? Or is there a better approach to solve this problem?
I see two main ways of distributing your source code to the different supercomputers:
tarballs generated by make dist
version controlled source tree
If you are using make dist generated tarballs (case 1) to distribute your source code to the different supercomputers, you can use one single source tree extracted from the tarball for all different supercomputers, as long as you do out of source tree builds in different per-supercomputer directories.
If you are using a version controlled source tree (case 2) for both developing your source code and distributing it to the different supercomputers, you have two options:
keep the make dist generated files inside version control
keep all generated files outside version control
If you keep the make dist generated files inside of version control (case 21), every autoreconf run on a machine different to the one which generated those files will produce a changed set of generated files, and thus changes to the files without actual raw changes. So in this case, you need to define a single system on which you all development work which touches the build system. All other systems can only do development inside the source code. Then you can use one single version controlled source tree on all different supercomputers.
If you keep all generated files outside of version control (case 22), you will need different copies of the version controlled source tree for each different machine to avoid the tool version mismatches.
In the age of distributed version control systems like git, this (case 22) would clearly be my preferred option.
I'm trying to compile a code to run in parallel on a supercomputer. I know that others have compiled this code to run on the same computer, but for some reason I am having trouble even when using the same methodology as them. For now I'm just trying to compile the code to run in serial as that should be easier to troubleshoot.
configure seems to work correctly.
However make install returns the following:
> make install
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh /home1/username123/code123/config/missing aclocal-1.13 -I ./config -I /home1/username123/code123/build-tools/aclocal -I /usr/local/share/aclocal
aclocal-1.13: error: couldn't open directory '/usr/local/share/aclocal': No such file or directory
Makefile:534: recipe for target '../aclocal.m4' failed
make: *** [../aclocal.m4] Error 1
aclocal is indeed not located at /usr/local/share/aclocal, it is located at /usr/bin/aclocal - but as /usr/bin is in my path, I don't understand why the location is an issue.
As has been made clear in comments on the question, the problem was that the project sources were copied onto the target system in a way that failed to preserve their original timestamps. The Autotools, through make, use file timestamps to determine which files are out of date, and in particular, Autools-generated Makefiles contain rules for rebuilding the build system itself that can be triggered this way.
It is not ordinarily necessary or desirable to rebuild an Autotools project's build system, except in conjunction with actually performing maintenance on it. It is often the case, in fact, that the necessary support for that is not available locally. To avoid the build system thinking that it needs to rebuild itself, it is important to preserve the file timestamps from the distribution archive. For some packages, it also works to pass the --disable-maintainer-mode argument to the configure script, but by no means do all Autotools configure scripts support that.
The archive extraction tools for the typical archive formats in which Autotools-based packages are distributed do, by default, preserve timestamps when unpacking, so the ordinary procedure of
unpack the archive on the target system (e.g. tar xzf foo-1.2.3.tar.gz)
change to the unpacked source directory (e.g. cd foo-1.2.3)
configure; make; make install
normally does the right thing. Substituting something else for (1), however, such as copying the unpacked source tree from somewhere else, may cause the package to think it needs to rebuild the build system. If that works correctly then it's no big deal, but it is not uncommon that it doesn't. That's what happened here, and following the standard procedure described above solved the problem.
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