Re: aclocal does not add LIBTOOL macros?
On Sat, May 05, 2007 at 11:48:07PM +0200, Tsuna <[EMAIL PROTECTED]> wrote a message of 26 lines which said: > > The problem was that the FreeBSD port of automake (I used only > > official ports) ... > I'd rather advise you to install libtool (and autoconf, if you > haven't done so) from ports, That's exactly what I did (and wrote).
Re: aclocal does not add LIBTOOL macros?
On Sat, May 05, 2007 at 05:13:25PM +0200, Tsuna <[EMAIL PROTECTED]> wrote a message of 42 lines which said: > Looks like aclocal does not know where libtool.m4 is. Thanks for the very good tip. The problem was that the FreeBSD port of automake (I used only official ports) installed aclocal macros in /usr/local/share/aclocal19 while all the other ports (such as libtool or gettext) were installed in /usr/local/share/aclocal and therefore not found. By merging the two directories and making a symbolic link, everything now works.
aclocal does not add LIBTOOL macros?
I always have problems bootstrapping auto* programs. This time, automake's aclocal apparently does not do what it should. The program uses libtool: % grep LIBTOOL configure-common.ac AC_LIBTOOL_DLOPEN AC_PROG_LIBTOOL (configure-common.ac is included by configure.ac) aclocal does not add LIBTOOL macros: % aclocal /usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal % grep LIBTOOL aclocal.m4 % And, of course, autoconf complains: % autoconf configure:2125: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:2126: error: possibly undefined macro: AC_PROG_LIBTOOL I can use libtoolize: % libtoolize Remember to add `AC_PROG_LIBTOOL' to `configure.ac'. You should update your `aclocal.m4' by running aclocal. libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite but it changes nothing, aclocal still does the wrong thing. On other machines, I can run aclocal on the same tree and it does create an aclocal.m4 with LIBTOOL macros. The faulty machine is: % uname -a FreeBSD esther.generic-nic.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Tue Jan 30 10:03:08 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ESTHER i386 % aclocal --version aclocal (GNU automake) 1.9.6 Written by Tom Tromey <[EMAIL PROTECTED]> Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % libtoolize --version libtoolize (GNU libtool) 1.5.22 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. signature.asc Description: Digital signature
Re: Makefiles and libraries problem
On Wed, Apr 11, 2007 at 08:40:30PM -0300, Matías Alejandro Torres <[EMAIL PROTECTED]> wrote a message of 109 lines which said: > The command `make` throws an error when trying to build the database > directory that says that there is no rule to build the objective > `all` Shot in the dark: did you run automake (and probably autoconf) in all the subdirectories? Is there a Makefile in database/?
Re: Lost in automatic dependencies
On Thu, Apr 05, 2007 at 05:09:44PM +0200, Ralf Wildenhues <[EMAIL PROTECTED]> wrote a message of 21 lines which said: > Just making sure: you said you removed config.cache, but what about > $prefix/var/tmp/config.cache? You're right. I deleted config.cache, $prefix/var/tmp/config.cache, restored my config.site and rebuilt everything and it works. I now have automatic dependencies. Thanks again.
Re: Lost in automatic dependencies
On Fri, Mar 30, 2007 at 12:13:26AM +0200, Ralf Wildenhues <[EMAIL PROTECTED]> wrote a message of 16 lines which said: > This shows the result as loaded from the cache file (config.cache) > or possibly from /usr/local/etc/config.site, Indeed, removing /usr/local/etc/config.site solved the problem (the cache was innocent; I've already tried to delete it.) Now, when I modify ".h" files, everything is compiled again. And I get: configure:19140: checking dependency style of cc configure:19230: result: gcc3 configure:19249: checking dependency style of g++ configure:19339: result: gcc3 configure:19576: checking for gcc So, we've found the guilty, thanks. Here is the config.site in case someone finds the bug in it: # config.site for configure. See (autoconf) Site Defaults # # Give Autoconf 2.x generated configure scripts a shared default # cache file for feature test results, architecture-specific. if test "$cache_file" = /dev/null; then if test "$prefix" = NONE; then prefix=$ac_default_prefix fi cache_file="$prefix/var/tmp/config.cache" if ! test -d `dirname $cache_file`; then mkdirhier `dirname $cache_file` fi # A cache file is only valid for one C compiler. # We have strange autoconf problems with gcc3/pkg #CC=/usr/pkg/gcc3/bin/gcc #LD=/usr/pkg/gcc3/bin/gcc #LD=env #CPP=/usr/pkg/gcc3/bin/cpp #CXX=/usr/pkg/gcc3/bin/c++ #CPLUSPLUS=$CXX CC=gcc fi # Use the packages CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib # Otherwise, libtool tries to use it even for pure-C programs! F77=false # Use GNUTLS with_gnutls=yes
Re: Lost in automatic dependencies
On Wed, Mar 28, 2007 at 11:45:47PM +0200, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > so please enclose AM_INIT_AUTOMAKE in `set -x', `set +x' in > configure.ac, add `set -x' as second line to depcomp, run autoconf > and configure. Send output. Here it is. dep-problem.txt.gz Description: Binary data
Re: Lost in automatic dependencies
On Wed, Mar 28, 2007 at 11:16:32PM +0200, Ralf Wildenhues <[EMAIL PROTECTED]> wrote a message of 27 lines which said: > How exactly was configure invoked ./configure --config-cache > and could you show the configure.ac up to AC_PROG_CXX? I did not invoke AC_PROG_CXX (there is no C++ in the code), I assume libtool did it for me. You can get the whole program from ftp://ftp.internatif.org/pub/unix/echoping/echoping-6.0.0..tar.gz which should be simpler :-) > What version is the depcomp script anyway? depcomp 2005-07-09.11
Re: Lost in automatic dependencies
On Wed, Mar 28, 2007 at 10:48:24PM +0200, Ralf Wildenhues <[EMAIL PROTECTED]> wrote a message of 16 lines which said: > Please show the configure output around "checking dependency style". gcc version 3.3.3 (NetBSD nb3 20040520) ... configure:19139: checking dependency style of cc configure:19229: result: none configure:19248: checking dependency style of g++ configure:19338: result: none > Please also show the setting of CCDEPMODE in the Makefile. CCDEPMODE = depmode=none > Please also show the bit of the Makefile.am where you specify the C > program and its sources. bin_PROGRAMS = echoping man_MANS = echoping.1 echoping_SOURCES = echoping.c error.c readline.c writen.c util.c http.c icp.c HTParse.c echoping.h icp.h HTParse.h smtp.c pkginclude_HEADERS = echoping.h compilation.h echoping_LDADD = echoping_LDFLAGS = -export-dynamic > does the Makefile in question contain a line of the form include > ./$(DEPDIR)/objectname.Po Yes include ./$(DEPDIR)/HTParse.Po include ./$(DEPDIR)/echoping.Po ... > does the file .deps/objectname.Po exist, and what does it contain? % cat .deps/echoping.Po # dummy
Lost in automatic dependencies
It seems that my C program does not track dependencies. If I touch a ".h", nothing is recompiled. I did *not* use "no-dependencies". Reading the FM, it seems I should have automatic dependencies tracking but I do not have. automake (GNU automake) 1.9.6 gcc 4.1.2 or 3.3.3 GNU Make 3.81
Re: automake does not install mkinstalldirs?
On Mon, Mar 12, 2007 at 12:28:25PM +0100, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote a message of 15 lines which said: > "make dist" uses it... On the very same machine. May be Makefile was > built with an older automake, I'll check. Indeed, rebuilding all the Makefile.in in the subdirectories solved the problem (this tree was in use for a long time). Thanks.
Re: automake does not install mkinstalldirs?
On Mon, Mar 12, 2007 at 12:04:27PM +0100, Daniel Leidert <[EMAIL PROTECTED]> wrote a message of 21 lines which said: > automake >= 1.8 prefers mkdir over mkinstalldirs if available Yes, this was a Debian machine, where mkdir -p works. > You would have to copy it yourself, if you still need it. "make dist" uses it... On the very same machine. May be Makefile was built with an older automake, I'll check.
automake does not install mkinstalldirs?
"automake --add-missing" installs what I want except mkinstalldirs: echoping/trunk/SRC % automake --add-missing echoping/trunk/SRC % ls -l mkinstalldirs ls: mkinstalldirs: No such file or directory Therefore, "make dist" fails. Of course, I can do a symlink myself but I wonder why does automake ignores this file? automake 1.9.6
Re: AC_DEFINE problem
On Thu, Sep 02, 2004 at 08:40:29PM +0200, Frederik Fouvry <[EMAIL PROTECTED]> wrote a message of 23 lines which said: > [AC_DEFINE(SVR4) ... > autoheader: warning: missing template: SVR4 > autoheader: Use AC_DEFINE([SVR4], [], [Description]) AC_DEFINE(SVR4,,[We run on System V Release 4])
Re: aclocal and libtool don't get along
On Mon, Jul 19, 2004 at 01:25:12PM -0400, Vance Shipley <[EMAIL PROTECTED]> wrote a message of 31 lines which said: > $ aclocal > configure.ac:2: /usr/local/bin/m4: ERROR: Reading inserted file: No such file or > directory I suspect that a M4 included file is actually a dangling symlink. Goto /what/ever/aclocal and 'ls -l libtool*'. Or use strace/truss/whatever (you did not indicate your OS) to see what file aclocal was trying to open.
Re: automake for plugins (no PROGRAMS, no LIBRARIES)
On Fri, Apr 02, 2004 at 12:04:18PM +0200, Andreas Schwab <[EMAIL PROTECTED]> wrote a message of 18 lines which said: > Use libtool with -module. That's what I eventually did. The actual configuration in Makefile.am is: pkglib_LTLIBRARIES = whois.la whois_la_SOURCES = whois.c whois_la_LDFLAGS = -module And the main program: bin_PROGRAMS = echoping man_MANS = echoping.1 echoping_SOURCES = echoping.c error.c readline.c writen.c util.c http.c icp.c HTParse.c echoping.h icp.h HTParse.h smtp.c echoping_LDADD = echoping_LDFLAGS = -export-dynamic Thanks.
Re: Subdirectories: automake wants GNU mandatory files in every directory
On Thu, Jun 03, 2004 at 09:29:38PM +0200, Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote a message of 35 lines which said: > If there is a config.stats in plugins/example/foobar there is also a > configure and a configure.(in|ac). So foobar is the top-level > directory of a subpackage, and Automake rightly requires top-level > files in that directory. OK, I modified my application by adding AM_INIT_AUTOMAKE(foreign) in every subdirectory. Not pretty, but it works.
Subdirectories: automake wants GNU mandatory files in every directory
I use automake for a project with subdirectories (here a test with a dummy program). When I change a Makefile.am in a subdirectory, 'make' cannot rebuild the files because it runs automake with the --gnu option, which is fine for the topmost directory, but not for subdirectories which do not have INSTALL, README, etc. automake returns an error status (so make stops) but Makefile.in is created so the next time, things are fine. Tested with automake 1.8.3 on netBSD and automake 1.8.5 on Debian. kiwi:Programmation/C/automake-plugins % make make all-recursive Making all in plugins Making all in example Making all in foobar cd . && /bin/sh /home/bortzmeyer/Programmation/C/automake-plugins/missing --run automake-1.8 --gnu Makefile Makefile.am: required file `./INSTALL' not found Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Makefile.am: required file `./COPYING' not found *** Error code 1 Stop. make: stopped in /home/bortzmeyer/Programmation/C/automake-plugins/plugins/foobar *** Error code 1 Stop. make: stopped in /home/bortzmeyer/Programmation/C/automake-plugins/plugins *** Error code 1 Stop. make: stopped in /home/bortzmeyer/Programmation/C/automake-plugins *** Error code 1 Stop. make: stopped in /home/bortzmeyer/Programmation/C/automake-plugins kiwi:Programmation/C/automake-plugins % make make all-recursive Making all in plugins Making all in example Making all in foobar cd . && /bin/sh ./config.status Makefile depfiles config.status: creating Makefile config.status: executing depfiles commands
Re: simple Q: linking against another static lib
On Wed, Jun 02, 2004 at 08:56:31PM -0500, joseph speigle <[EMAIL PROTECTED]> wrote a message of 51 lines which said: > Oh, BTW fedora core 2 automake > > [EMAIL PROTECTED] Apache]# rpm -qa | grep automake > automake16-1.6.3-2 > automake17-1.7.9-2 > automake14-1.4p6-9 > automake-1.8.3-1 > automake15-1.5-10 > [EMAIL PROTECTED] Apache]# It does not tell which one is actually used. I assume each package installs an executable automake-VERSION and there is a symbolic link to a specific version. It would be better to indicate the output of 'automake --version'.
Re: automake for plugins (no PROGRAMS, no LIBRARIES)
On Fri, Apr 02, 2004 at 12:04:18PM +0200, Andreas Schwab <[EMAIL PROTECTED]> wrote a message of 18 lines which said: > Use libtool with -module. Must I? I mean, I never used libtool, I do not need it until now.
automake for plugins (no PROGRAMS, no LIBRARIES)
I modify an existing program to add the opportunity to load plugins. They will be small '.so' files (not ".a") loaded by dlopen. The program uses automake. Reading automake's documentation, I cannot find an easy way to use it. The node "Programs and libraries" about primaries talk only of: >Use the `PROGRAMS' primary for programs, `LIBRARIES' for libraries, >and `LTLIBRARIES' for Libtool libraries None is convenient: PROGRAMS are not compiled with the proper flags and LIBRARIES have naming rules I disagree with (`dummy.so' is not a standard library name"). Reading http://sources.redhat.com/ml/automake/2000-08/msg00015.html>, which had no reply, it seems there is no solution in the Automake framework.
