I am on a Windows computer but working with the cygwin subsystem.
I have followed some manuals on how to download gmp. I have therefor downloaded, unzipped and configured the gmp-6.2.1 file, but i come onto problems in the "make" step.
In the gmp-6.2.1 file there are two makefiles, and when i try to use "make" on them i get:
$ make -f Makefile.in
Makefile.in:15: *** missing separator. Stop.
Where line 15 in Makefile.in is
#SET_MAKE#
and
$ make -f Makefile.am
Makefile.am:126: *** missing separator. Stop.
Where line 126-130 in Makefile.am is
if WANT_CXX
GMPXX_HEADERS_OPTION = gmpxx.h
pkgconfig_DATA += gmpxx.pc
endif
Do you know if I need to change anything in the makefiles, or something else?
Thanks for the help.
Makefile.in and Makefile.am are not makefiles. It is erroneous to use make -f to try to interpret them as such. These are contributors to building a makefile for the project.
You're looking at a project with a GNU build system. The standard procedure for building such a project is to
run the ./configure script to generate one or more makefiles and perhaps other files, then
run make in the same working directory to build the project, then
run make install in that directory to install the built result to the system.
There are variations and embellishments that can be made, but that's the basic pattern. Nowhere should you need to use make's -f option.
If the instructions you're following are any good then they will have covered this at least briefly.
Related
I'm trying to ensure that some non-source files are generated when make dist is executed. The files are an info file and an index which is constructed from the info file. I find that the files are generated when I execute make install but not when I execute make dist.
Here is the Makefile.am. (This is share/logic/Makefile.am in the Maxima project, if anybody cares.)
all-local: info
info: logic.info logic-index.lisp
logic.info: logic.texi
makeinfo --force logic.texi
logic-index.lisp: logic.info
perl ../../doc/info/build_index.pl $< > $#
Somehow I got the idea that the target all-local could cause the info and index to be rebuilt. That works OK for make install -- I guess all-local is a target for that. But all-local is not, it appears, a target for make dist. What other target could I use to ensure that the logic.info and logic-index.lisp are rebuilt for make dist as well as make install?
I have searched the web, and SO, and tried some random things, but so far I've come up empty-handed. Thanks in advance for your help.
I'm working with GNU make 3.81, GNU automake 1.14.1, and GNU autoconf 2.69, on Ubuntu 14.04.
You can force something to be built and included in the package by using EXTRA_DIST, so in your case
EXTRA_DIST = logic-index.lisp
This will cause the file to be always included in the distribution tarball.
I want to install ratfor77 on Cygwin (form the Stanford Exploration Project).
I downloaded it, untar it, attribute the good permissions to the folder ratfor77 (chmod -R u+w ratfor77).
But when I want to use the command make all I receive this error:
make: *** No rule to make target '/ratfor77', needed by 'all'. Arrêt.
I verified that all the files needed were in the folder.
Any idea?
The makefile does not follow the usual conventions. Run make ratfor77. Several compiler warnings are emitted but the executable ./ratfor77 is generated.
The problem I describe was resoluted by moving the raffor folfer to the root directory of Cygwin.
I had the message above:
Done making all in util/tools/ratfor77
I'm following a documentation but it do not work :p
But I didn't have the file ratfor.exe.
So I tried your code:
make rartfor77
And no it's ok.
Thank you very much Mike.
I'm currently learning how to use the autoconf/automake toolchain. I seem to have a general understanding of the workflow here - basically you have a configure.ac script which generates an executable configure file. The generated configure script is then executed by the end user to generate Makefiles, so the program can be built/installed.
So the installation for a typical end-user is basically:
./configure
make
make install
make clean
Okay, now here's where I'm confused:
As a developer, I've noticed that the auto-generated configure script sometimes won't run, and will error with:
config.status: error: cannot find input file: `somedir/Makefile.in'
This confuses me, because I thought the configure script is supposed to generate the Makefile.in. So Googling around for some answers, I've discovered that this can be fixed with an autogen.sh script, which basically "resets" the state of the autoconf environment. A typical autogen.sh script would be something like:
aclocal \
&& automake --add-missing \
&& autoconf
Okay fine. But as an end-user who's downloaded countless tarballs throughout my life, I've never had to use an autogen.sh script. All I did was uncompress the tarball, and do the usual configure/make/make install/make clean routine.
But as a developer who's now using autoconf, it seems that configure doesn't actually run unless you run autogen.sh first. So I find this very confusing, because I thought the end-user shouldn't have to run autogen.sh.
So why do I have to run autogen.sh first - in order for the configure script to find Makefile.in? Why doesn't the configure script simply generate it?
In order to really understand the autotools utilities you have to remember where they come from: they come from an open source world where there are (a) developers who are working from a source code repository (CVS, Git, etc.) and creating a tar file or similar containing source code and putting that tar file up on a download site, and (b) end-users who are getting the source code tar file, compiling that source code on their system and using the resulting binary. Obviously the folks in group (a) also compile the code and use the resulting binary, but the folks in group (b) don't have or need, often, all the tools for development that the folks in group (a) need.
So the use of the tools is geared towards this split, where the people in group (b) don't have access to autoconf, automake, etc.
When using autoconf, people generally check in the configure.ac file (input to autoconf) into source control but do not check in the output of autoconf, the configure script (some projects do check in the configure script of course: it's up to you).
When using automake, people generally check in the Makefile.am file (input to automake) but do not check in the output of automake: Makefile.in.
The configure script basically looks at your system for various optional elements that the package may or may not need, where they can be found, etc. Once it finds this information, it can use it to convert various XXX.in files (typically, but not solely, Makefile.in) into XXX files (for example, Makefile).
So the steps generally go like this: write configure.ac and Makefile.am and check them in. To build the project from source code control checkout, run autoconf to generate configure from configure.ac. Run automake to generate Makefile.in from Makefile.am. Run configure to generate Makefile from Makefile.in. Run make to build the product.
When you want to release the source code (if you're developing an open source product that makes source code releases) you run autoconf and automake, then bundle up the source code with the configure and Makefile.in files, so that people building your source code release just need make and a compiler and don't need any autotools.
Because the order of running autoconf and automake (and libtool if you use it) can be tricky there are scripts like autogen.sh and autoreconf, etc. which are checked into source control to be used by developers building from source control, but these are not needed/used by people building from the source code release tar file etc.
Autoconf and automake are often used together but you can use autoconf without automake, if you want to write your own Makefile.in.
For this error:
config.status: error: cannot find input file: `somedir/Makefile.in'
In the directory where the configure.ac is located in the Makefile.am add a line with the subdirectory somedir
SUBDIRS = somedir
Inside somedir put a Makefile.am with all the description. then run automaker --add-missing
A better description can be found in 7.1 Recursing subdirectories automake manual.
https://www.gnu.org/software/automake/manual/automake.html
I have started recently to work with automake and autoconf and I am a little confused about how to distribute the code.
Usually when I get a code that works with a configure file, the only thing that I get is a confiure file and the code itself with the Makefile.am and so on. Usually I do
./configure
make
sudo make install
and thats all but when I generate my configure from a configure.ac file it toss out lots of files that I thought where just temporary but if I give the code to a partner and he makes configure, it doesn't work, it needs either remake the autoreconf or have all this files (namely instal.sh,config.sub...).
Is there something that I am missing? How can I distribute the code easily and clean?
I have searched a lot but I think I am searching for the right thing because I cannot find anything useful.
Thanks a lot in advance!
Automake provides a make dist target. This automatically creates a .tar.gz from your project. This archive is set up in such a way that the recipient can simply extract it and run the usual ./configure && make && make install invocation.
It is generally not recommended to check the files generated by Autotools into your repository. This is because they are derived objects. You wouldn't check in your .o files!
Usually, it is a good idea to provide a autogen.sh script that carries out any actions required to re-create the Autotools build infrastructure in a new version control system checkout. Often, it can be as simple as:
#!/bin/sh
autoreconf -i
Then set it chmod +x, and the instructions for compiling from a clean checkout can be ./autogen.sh && ./configure && make.
I am trying to install a rubygem which keeps on trying to read a library which is not available.
grep: /usr/lib64/libgdbm.la: No such file or directory
/bin/sed: can't read /usr/lib64/libgdbm.la: No such file or directory
libtool: link: /usr/lib64/libgdbm.la' is not a valid libtool archive
In order to work around this, I installed my own libgdbm and provided the path to the libgdbm in the makefile LDFLAGs but to no avail.
Any help is much appreciated.
This rubygem seems to do dirty stuff, since any clean library search (-L or pkg-config) would have resulted in a message like "library/package gdbm not found". And especially the grep-and-sed procedure on the la file seems really dirty. Make sure Santa knows that the author of this gem gets no presents this year.
The gem probably has the path to the libtool archive hardcoded. First of all, try to grep for /usr/lib64/libgdbm.la in the Makefile of the gem. Change the hardcoded path, and make sure the installation script has no write permissions on any system directories, because it seems to run wild with seds.
Libtool requires intimate knowledge of your compiler suite and operating system in order to be able to create shared libraries and link against them properly. When you install the libtool distribution, a system-specific libtool script is installed into your binary directory.
However, when you distribute libtool with your own packages, you do not always know the compiler suite and operating system that are used to compile your package.
For this reason, libtool must be configured before it can be used. This idea should be familiar to anybody who has used a GNU configure script. configure runs a number of tests for system features, then generates the Makefiles (and possibly a config.h header file), after which you can run make and build the package.
Libtool adds its own tests to your configure script in order to generate a libtool script for the installer's host machine. For this you can play with LT_INIT macro in configure.ac.
So in short, if your package has configure file, run it before running Make
make distclean //clean up all the previous generated files
autoconf //or autoreconf to generate configure script from configure.ac and configure.in
automake //to generate new Makefile.in from Makefile.ac
./configure //to generate new Makefile and libtool