i'm tackling the problem of compiling vmime library using this guide with MinGW. As this guide states, first i need to compile libiconv library with these commands(yep i'm new to MinGW):
$ tar -xvvzf libiconv-1.13.1.tar.gz
$ cd ./libiconv-1.13.1
$ ./configure --prefix=/mingw #configures makefile, use /mingw as a prefix
$ make
$ make install
after all this commands the libiconv.dll.a appears in libiconv-1.13.1\lib.libs
directory.Also after compiling process appears the /bin directory and there is only 1 library - libcharset-1.dll.
My question is - how do i know if the library properly compiled, without errors?Should i check the output from the MSYS console? there are tons of checks, it seems pretty boring task. Thanks in advance, glad to hear any advice!
You're building a GNU Autotools package.
./configure generates the makefile(s) needed by make to build the library
on your particular system. If it thinks the library can't be built on your particular
system, it will tell you why. It might just miss some reason why you can't build
the library, because the library developer(s) have to script the tests that it runs, and might
just overlook some necessary ones. But if it misses something then make will fail.
make executes all the commands necessary to build the library on your system. If any of them fail,
then make will fail, and will tell you so unmistakably.
Likewise make install does everything necessary to install the library
under the default or specified prefix path.
Classically, unix tools (like the autootols) will inform you when something goes wrong
and not inform you that nothing went wrong.
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I am trying to build a library with a different build system, but files in the library require a config.h header file that is generated after running the configure scripts generated by autoconf.
This is the sequence of steps I am following to try and generate the config.h file that is needed
autoreconf -ivf
./configure --disable-dependency-tracking
The build system guarantees that the library gflags will be linked and the headers will be available at preprocessing time. But the configure script exits with the following error
configure: error: Please install google-gflags library
Is there some way I can get the list of required libraries (such as gflags) and then pass arguments to the configure script that tells it to assume that this library exists on the system? I went through the help output for both autoreconf and ./configure and wasn't able to figure this out.
Sorry for the long explanation and problem. I am very new to autoconf, etc.
The answer to your question is: no, it is not possible to get a list of dependencies from autotools.
Why?
Well, autotools doesn't track dependencies at all.
Instead, it checks whether specific features are present on the system (e.g. a given header-file; or a given library file).
Now a specific header file can come from a variety of sources, e.g. depending on your distribution the foo.h header can be installed via
libfoo-dev (Debian and derivatives)
foo-devel (Fedora)
foo (upstream)
...
In your specific case, the maintainers of your project output a nice error message telling you to install a given package by name.
The maintainers of your project also chose to abort with a fatal error if a given dependency is not available.
The reason might well be, that the project simply won't work without that dependency, and that is impossible to compile the program without it.
Example
Your project might be written in C++ and thus require a C++-compiler.
Obviously there is little use in passing some flags to ./configure so it assumes that there is a C++-compiler available if in reality there is none.
There is hope
However, not all is bad.
Your configure script might will have the ability to disable certain features (that appear to be hard requirements by default).
Just check ./configure --help and look for flags like
--enable-FOO
--disable-FOO
--with-BAR
--without-BAR
automation?
One thing to know about autotools, is that configure really is a program (the source-code being configure.ac) written in some arcane programming language (involving bash and m4),
This means that it can practically have any behavior, and there is no single standard way to achieve "dependecy tracking".
What you're trying to do will not work as umläute already said. On the other hand, depending on the package you're trying to build, you may be able to tell ./configure that a given library is there even if it isn't.
For instance if the script uses pkg-config to check for the presence of a library, you can use FOO_CFLAGS and FOO_LIBS to override the presence checking and telling it "yes those packages are there, you just don't know how to find them", but these are very package-specific so you may have to provide more information if that's what you're looking for.
I'm working on a Windows 7 computer at work and want to use the libpostal package. Unfortunately, it's apparently not available for Windows, so I'm trying to configure it through Cygwin and I'm SO close. The last step is to install snappy from Google. Again, not available on Windows...
My assumption (based on nothing) is that I can just download the tarball and build it from source, right? I tried that, and I think it worked? But a) I don't know how to tell, and b) if it did, I don't know how to tell ./configure in libpostal to find it.
In order to build it from source, I downloaded the tarball and saved it in the folder that Cygwin reads as my home, which is C:\cygwin64\home\brittenb\. From there, I ran bash autogen.sh, which created the ./configure that I needed. So I ran that and while some responses to the checks were no, it seemed to run fine. I then ran make and make install. Nothing seemed out of place, so my assumption is that it did what it was supposed to do. I just have no idea where to go from here.
Here is the output from ls after I run everything:
aclocal.m4 snappy.cc
AUTHORS snappy.h
autogen.sh snappy.lo
autom4te.cache snappy.o
ChangeLog snappy.pc
compile snappy.pc.in
config.guess snappy_unittest.cc
config.h snappy_unittest.exe
config.h.in snappy_unittest-snappy_unittest.o
config.log snappy_unittest-snappy-test.o
config.status snappy-c.cc
config.sub snappy-c.h
configure snappy-c.lo
configure.ac snappy-c.o
COPYING snappy-internal.h
depcomp snappy-sinksource.cc
format_description.txt snappy-sinksource.h
framing_format.txt snappy-sinksource.lo
INSTALL snappy-sinksource.o
install-sh snappy-stubs-internal.cc
libsnappy.la snappy-stubs-internal.h
libtool snappy-stubs-internal.lo
ltmain.sh snappy-stubs-internal.o
m4 snappy-stubs-public.h
Makefile snappy-stubs-public.h.in
Makefile.am snappy-test.cc
Makefile.in snappy-test.h
missing stamp-h1
NEWS testdata
README test-driver
ls /usr/local/bin shows nothing, but ls /usr/local/include shows:
snappy.h snappy-c.h snappy-sinksource.h snappy-stubs-public.h
So... my question: did it work? Why does ./configure in libpostal say it can't find snappy? Thanks in advance.
The snappy dependency has been removed as of release 1.0.0. I made changes to the source and make and config so that it will build on MinGW.
Get it in my repository:
https://github.com/BenK10/libpostal_windows
Note that this is not the complete source since not everything had to be changed. I would suggest merging my changes with the official libpostal distribution to make sure you've got everything. Also, there are some extra DLLEXPORTs in some source files that I haven't removed yet, and the part in the Makefile that builds the executables like address_parser.exe was removed because some porting is necessary to build those programs on Windows. You can write your own using the DLL you'll get in the Windows build and the original source as a reference.
Check the return code from make install ($?). If it is zero, make install succeeded.
snappy looks like a library, so maybe it doesn't install anything in /usr/local/bin. The library is probably installed into /usr/local/lib.
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'm new to NX OSes, actually MacOS, and when I try to build sources with make and makefiles, I never can.
I try to run make, even try to run it passing the makefile as an argument, but all I get is "There's nothing for make to do"
Can you point me to a tutorial, reference, or something ?
This one is excellent.
(You can also read some criticism to round your knowledge.)
(If after reading these, you want to try cmake, then you want to go here. It works perfectly on Mac OS X.)
Generally if you're trying to install from a tarball there will be a file named README or INSTALL with installation instructions. Usually all you have to do is run from the terminal
./configure
make
sudo make install
It's generally possible to set options for compilation by adding flags to ./configure, to see what they are run
./configure --help
Here is a tutorial to help you get started.
Just remember to use tabs instead of spaces when indenting lines in the makefile :)