Re: Automake 1.16 build failure
On Feb 27 2018, Mathieu Lirzin wrote: > What is the Perl version used? 5.18.2 > Can you open a bug report on for this issue? Done. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Automake 1.16 build failure
$ make -j4 GEN bin/automake GEN bin/aclocal GEN t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN runtest GEN doc/aclocal.1 GEN doc/automake.1 GEN lib/Automake/Config.pm GEN t/ax/test-defs.sh GEN bin/aclocal-1.16 GEN bin/automake-1.16 GEN doc/aclocal-1.16.1 GEN doc/automake-1.16.1 help2man: can't get `--help' info from automake-1.16 Try `--no-discard-stderr' if option outputs to stderr Makefile:3694: recipe for target 'doc/automake-1.16.1' failed make: *** [doc/automake-1.16.1] Error 255 make: *** Waiting for unfinished jobs $ ./pre-inst-env automake-1.16 --help "none" is not exported by the List::Util module Can't continue after import errors at /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76. BEGIN failed--compilation aborted at /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: cross-compiling on 64 to 32-bit Linux
Jan Engelhardt writes: >>needs to use $CC/$CXX anyway. > > CCLD/CXXLD. Which default to $CC/$CXX anyway. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: cross-compiling on 64 to 32-bit Linux
Bruno Haible writes: > - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS. That should not be necessaray, since any command that uses $LDFLAGS needs to use $CC/$CXX anyway. > - The -m64 flag is the default on bi-arch Linux systems. This is wrong. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: rebuilding following a change in prefix?
Jan Engelhardt writes: > Well, automake (unfortunately?) does not currently issue a recompile > when the compiler command changed. > It would be really cool to have that, though. But that should be optional. I don't want to do a complete rebuild just because I want to do a quick recompile of a single object file with different options. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: rebuilding following a change in prefix?
Adam Mercer writes: > I have noticed some strange behaviour with the build system on a > project I am working on, consider the following: > > $ ./configure --prefix=/path/1 > $ make > $ make install > $ ./configure --prefix=/path/2 > $ make > $ make install I'd suggest using separate build directories for each build. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Setting shared lib version not functioning
John Calcote writes: > One thing that bothers me a little is that we never really did solve > Gerald's original problem. He said his library was created just fine when > he was passing 2:0:0, but when he switched to 2:0:1, it created a library > with a version number of 1:1:0. Now, why would Libtool do this? Granted, > he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So > why did Libtool convert it to 1:1:0? For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Spurious testsuite failures
I'm getting several failures in the automake testsuite, for example: FAIL: libtool.test (exit: 1) /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests:/opt/kde3/bin:/home/andreas/bin/ccache:/home/andreas/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/sbin:/usr/local/m68k-linux/gcc/bin:/usr/local/m68k-linux/bin:/usr/local/ia64-linux/bin:/usr/lib/git libtool: running libtool --version ltmain.sh (GNU libtool) 2.2.6 Written by Gordon Matzigkeit , 1996 Copyright (C) 2008 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. === Running test ./libtool.test ++ pwd /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/libtool.dir + cat + : + : + : + : + aclocal-1.10b -Werror -Wno-syntax -I /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests/../m4 -I /usr/local/share/aclocal -I /usr/share/aclocal aclocal: couldn't open directory `/usr/local/share/aclocal': No such file or directory + Exit 1 + set +e + exit 1 + exit 1 + exit_status=1 + cd /home/andreas/src/osc/automake/BUILD/automake-1.10b/tests + case $exit_status,$keep_testdirs in + test 0 '!=' 0 + echo ': exit 1' : exit 1 + exit 1 The problem is that /usr/share/aclocal/dirlist contains the (non-existing) directory /usr/local/share/aclocal. Normally aclocal would ignore such a directory, but by adding it explicitly with -I aclocal now complains. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Portable suffix rules question
Jan Engelhardt writes: > I reckon that %-style suffix rules (e.g. "%.o: %.c") are rather > unportable, but I wonder how the old-fashioned suffix rule for > > %.1: %.1.php > > would look like. There is none. A suffix rule can contain at most two periods, so the closest you can get is this: .php: Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: automake manual: distclean
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> This is not quite portable -- unless GNU find, which implies a
> path of "." if nothing else is specified, Solaris's explicitly requires
> a path to find. It should therefor read
>
> distcleancheck_listfiles = \
>find . -type f -exec sh -c 'test -f $(srcdir)/{} || echo {}' ';'
This isn't quite portable either. POSIX only requires that find -exec
substitutes in arguments consisting of exactly {}.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Generating Autotools files without autoreconf
Roberto Bagnara <[EMAIL PROTECTED]> writes: > In other words, we would need something that acts like autoreconf except > for the fact that it would not attempt to build configure from configure.ac. $ AUTOCONF=true autoreconf ... Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
John Calcote <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> John Calcote <[EMAIL PROTECTED]> writes: >> >>> Make is a two-pass utility. The first pass completely assimilates all >>> macro data specified in the Makefile. THEN, the second pass generates >>> the rule dependency tree. >> >> This is not true. Variable refences in target and dependency lists are >> expanded when they are read. Any later redefinition will not change >> them. >> >> Andreas. >> > > This is only true if you use ':=' assignment. You are mistaken. RTFM. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
John Calcote <[EMAIL PROTECTED]> writes: > Make is a two-pass utility. The first pass completely assimilates all > macro data specified in the Makefile. THEN, the second pass generates > the rule dependency tree. This is not true. Variable refences in target and dependency lists are expanded when they are read. Any later redefinition will not change them. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Problems with conditional sources
David Sveningsson <[EMAIL PROTECTED]> writes:
> Hi, I am having some problems with conditional sources. This is what I
> have in Makefile.am:
>
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = foo.cpp
> if WANT_BAR
> libfoo_la_SOURCES += a.cpp
> else
> libfoo_la_SOURCES += b.cpp
> endif
>
> AM_CPPFLAGS = -I${top_srcdir}/include
> libfoo_la_LDFLAGS = -version-info 0:0:0
>
> I have been reading both autoconf and automake manuals and as far as I can
> see the above should work. However the files (a.cpp or b.cpp) is always
> added at the bottom of the generated Makefile and are therefore not used
> in the compilation. No matter what I try I cannot get even the above code
> to generate a correct makefile but obviously I am doing something wrong.
Remove the indentation.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Warn: non-POSIX variable name
Brian Dessent <[EMAIL PROTECTED]> writes: > The difference with this method is that the values are computed once > when configure is run, and then substituted into the Makefile when it is > generated after configure has completed. When you use $(shell ...) the > value is not computed until you run make, and the result is not stored > anywhere so it is recomputed each time that make is run. Even worse, it is recomputed each time the variable is _used_, ie. for every compilation job started by make. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: How can I change shared library's version number?
"Steven Woody" <[EMAIL PROTECTED]> writes: > When I use autoconf/automake with its integrated libtool to build a > shared library, I got shared libraray named 'libfoo.so.0.0.0'. I > don't sure where the 0.0.0 comes from, and I don't like it. How can I > change it? I searched info page but found no answer. See (libtool)Versioning. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: bug in automake? Getting ARFLAGS to work...
Ed Hartnett <[EMAIL PROTECTED]> writes: > In order to build on AIX in 64-bit mode, I have to be able to set the > ARFLAGS, but I can't get that to work. No matter what I do, automake > ignores my ARFLAGS and just uses "cru". This is a libtool issue, nothing to do with automake. For whatever reason, libtool is using AR_FLAGS, not ARFLAGS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: build configuration help
John Calcote <[EMAIL PROTECTED]> writes: > The way you implement this is to use $(prefix)/lib, or $(libdir) in your > -R option, which will resolve to the configured library installation > directory - /home/bob/foo/lib. When you use -R like this, however, just > realize that this binary can only be installed on this one non-standard > location (it can still be installed in standard locations). You can use -R '$ORIGIN/../lib' to make the binary relocatable. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: proper autotools ordering?
[EMAIL PROTECTED] (Karl Berry) writes: > I've been using aclocal - autoheader - automake - autoconf for years, > but have no idea any more where I got that ordering. I see that > autoreconf runs autoconf before autoheader, and ah before am, so I > suppose this is it: > aclocal - autoconf - autoheader - automake. There is no real dependency between autoconf/autoheader/automake. The only requirement is that aclocal is run before any of them, and sometimes it has to be run twice if libtoolize enters the scene. > Whatever the answer is, I suggest adding it to the manual(s). The manual should recommend autoreconf if it doesn't already. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing an AC_CHECK to fail
"Michael B Allen" <[EMAIL PROTECTED]> writes: > So how to do I preset a cache variable before running configure? You can put it in the environment, or use config.site. See (autoconf)Site Defaults. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing an AC_CHECK to fail
"Michael B Allen" <[EMAIL PROTECTED]> writes: > So is there a way to tell a specific check to fail? You can preset the cache variable before running configure. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Makefile.am assistance
NightStrike <[EMAIL PROTECTED]> writes: > Ok. I just tested your idea, and I am going to move all .a custom > targets to a _DATA primary, and leave the _SCRIPTS primary for just > the custom executable targets (like crt1.o, etc). crt1.o is DATA as well. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: read-only git mirror of automake cvs repository
Jim Meyering <[EMAIL PROTECTED]> writes: > I admit it was took more than a few iterations to get it right. > One of the big points was to realize that cvsps' cache was causing > trouble. So I'm careful to make git-cvsimport run cvsps in such a > way that the cache can't interfere. > One way to do that is to point HOME= at an empty directory > for the git-cvsimport run. I think you should be able to use '-p -x' to pass -x to cvsps. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: multi-line AC_SUBSTs as targets in Makefile.am
William Pursell <[EMAIL PROTECTED]> writes: > I'd like to get away from AC_SUBST_FILE, but I don't see a way > around the manner in which automake is building the Makefile. > Is there a way to construct a generic target via AC_SUBST? How about using AM_CONDITIONAL instead? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: strange choice of compiler on HP-UX
[EMAIL PROTECTED] (Bob Proulx) writes: > Since on HP-UX with the optional HP ANSI C compiler installed 'cc' is > a symlink in /usr/bin and also /bin on HP-UX is a symlink to /usr/bin > resulting in a single large bin directory with everything in it all in > one place so it would be difficult to change this by adjusting PATH. You are free to create your own directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: strange choice of compiler on HP-UX
Joao Miguel Ferreira <[EMAIL PROTECTED]> writes: > Question: How do I tell the tools to use only aCC for both types of > files, when compiling on an HPUX (we also build on Linux/gcc and > Solaris/gcc) ? ./configure CC=foo CXX=bar > PS: the cc is a link in /usr/bin that point to /opt/ansic/bin/cc !!! I > am not root of this system :-( You don't need to be root to change PATH. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ${} and $()
Jan Engelhardt <[EMAIL PROTECTED]> writes: > (And the stupid reply: am I on automake@gnu.org or [EMAIL PROTECTED] :-) automake both about makefiles and configue scripts. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ${} and $()
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> is there any real difference between $(var) and ${var}, and is the
> latter as much POSIX as the first?
Depends on the context. For a shell there is a big difference between
them. When interpreted by make they are identical.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: multiple cpu's
Bob Rossi <[EMAIL PROTECTED]> writes: > Can automake take advantage of multiple cpu's? This has nothing to do with automake. Just use the appropriate switch for make to enable parallel execution. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: PING: Automake list
NightStrike <[EMAIL PROTECTED]> writes: > Where should I look instead for automake archives? Since the list is @gnu.org, you should be looking at lists.gnu.org. (Also, Gmane is a good place to look.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: %-style pattern rules
Lorenzo Bettini <[EMAIL PROTECTED]> writes: > Ralf Wildenhues wrote: >> Hello Lorenzo, >> >> * Lorenzo Bettini wrote on Fri, Jul 27, 2007 at 05:18:48PM CEST: >>> and what if I need two files (with two different extensions) depend on >>> a single file? >> >> That is not possible portably, i.e., with inference rules. So either >> you can just choose to rely on GNU make, or write one rule per instance. > > apart from multiple files, I also tried to update some Makefile.am as > follows: > > SUFFIXES = .cc.html .cs.html .h.html > > .cs.cs.html: > $(CSHARP2HTML) -i $< -o $@ This is not a recognized suffix rule, you'll have to register the .cs suffix manually. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Circular dependecy linker trouble
Søren Boll Overgaard <[EMAIL PROTECTED]> writes: > Framework code depends on services code and vice versa. > Linking fails to resolve dependencies. The linker command line > essentially looks like this: > > g++ -g -O2 ../src/framework/libframework.a ../src/services/ > liblmsservices.a -o program main.o -lpthread Note that the command line as shown won't pull anything from the archives, because at the time they are processed there are no unresolved symbols yet (except for the symbol main). You should always list the libraries after the objects that reference symbols out of them. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: generated ChangeLog
Stepan Kasal <[EMAIL PROTECTED]> writes: > if a projects wants to generate ChangeLog dynamicly, from a > versioning system, by a make rule, how it can be done? > If you write the rule for ChangeLog to Makefile.am, then Automake > complains that the file does not exist at the time Automake is run. If you use AUTOMAKE_OPTIONS = foreign then automake should not complain. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Desktop file and exec path
Benoit Sigoure <[EMAIL PROTECTED]> writes: > Although two ways of solving this issue have been proposed already, there is > also another way out: using an AC_CONFIG_FILES. > > glpegsolitaire.desktop.in > -- > [Desktop Entry] > Name=Peg Solitaire > Comment=A "Peg Solitaire" for Gnome > [EMAIL PROTECTED]@ > Icon=glpegsolitaire.png > Terminal=false > Type=Application > Categories=GNOME;Game;BoardGame > StartupNotify=true > -- > > In your configure.ac: > AC_CONFIG_FILES([path/to/glpegsolitaire.desktop]) Such substitutions only work correctly in makefiles, since they can expand to references to other substituted variables that are supposed to be recursively expanded as done by make. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Desktop file and exec path
Enrico Sardi <[EMAIL PROTECTED]> writes: > glpegsolitaire.desktop > -- > [Desktop Entry] > Name=Peg Solitaire > Comment=A "Peg Solitaire" for Gnome > Exec=glpegsolitaire > Icon=glpegsolitaire.png > Terminal=false > Type=Application > Categories=GNOME;Game;BoardGame > StartupNotify=true > > -- > > and I want that if I give the command "make install" the path in the > Exec field will be replaced by the value of the $(datadir) variable. Is > this possible? Use @DATADIR@ in glpegsolitaire.desktop.in and put this in your makefile: glpegsolitaire.desktop: $(srcdir)/glpegsolitaire.desktop.in sed 's:@DATADIR@:$(datadir):' $(srcdir)/glpegsolitaire.desktop.in > glpegsolitaire.desktop.in Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: adding libraries and header file directories
"Jim Rainville" <[EMAIL PROTECTED]> writes:
> Doh! Sometimes I fail to see the forest for the trees. So I copied the
> link line and added the --perserve-dup-deps flag. Something weird
> happens here. It's cutting off a lot of the file names. I thought at
> first it was a copy and paste error but its not
It is almost certainly a paste error.
> [EMAIL PROTECTED] vlc-0.8.5]$ /bin/sh ./libtool --preserve-dup-deps
> --mode=link --tag=CC gcc -Wsign-compare -Wall -pipe -o vlc vlc -vlc.o
^^^
> src/libvlc.a -Wl,--start-group -lelem_chkpt_api -lelem_chmgmt_api
> -lelem_ core_api -lelem_mobj_api -lelem_fault_api -lelem_rel_api
etc.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: How do I get configuration files installed?
Jim Lynch <[EMAIL PROTECTED]> writes: > I'm trying to figure out how to add a file to be installed in > $prefix/bin/lib. Are you sure you want that and not $libdir or even $datadir? > But when I put > bin_SCRIPTS=bin/float.pl bin/work.pl bin/lib/cipher.txt > in there, it simply puts ciper.txt in bin also. How can I tell it that I > want that file to end up in bin/lib? binlibdir = $(bindir)/lib binlib_DATA = bin/lib/cipher.txt Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Eric Blake <[EMAIL PROTECTED]> writes: > If they really want to stop parsing options, and pass all remaining > arguments to gcc, then they should be using -- between the options they > give gcc and the remaining arguments that they pass unchanged. Which unfortunately does not work since gcc interprets -- as an ambigous abbreviation instead of the end-of-option-marker. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > The issue is > much more special in this case: the FreeBSD compiler wrapper c89 > accepts the options > -MP -MD -MF -MT > > if they appear _after_ all the other command line arguments, The wrapper probably just stops parsing options at the first non-option, and passes all remaining arguments unchanged. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Forcing static link of libstdc++
Mike Melanson <[EMAIL PROTECTED]> writes: > If I install gcc 4.0.2 as a separate compiler on > an older machine, I wonder if it will be an option to link to > libstdc++.so.5? That won't work. The C++ runtime library is tightly coupled with the compiler. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: convenience libraries & binary size
Pieter Grimmerink <[EMAIL PROTECTED]> writes: > 1. move all >200 sourcefiles back into a single directory... > 2. stop using autotools, so we no longer need convenience libs to handle > subdirectories You don't need convenience libraries to handle subdirectories. Have you tried subdir-objects? (*Note (automake)Options::.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes:
> Let me turn that around, and ask if you can provide any documentary
> evidence, other than anecdotal, to suggest that this use of semicolons
> *should* be supported? SUSv3 *expressly* demands that sed directives be
> separated by newlines:
> http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
"The command can be preceded by s and/or semicolons. The function
can be preceded by s. These optional characters shall have no
effect."
"Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed
by a semicolon, optional s, and another command verb."
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes: > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: >> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote: >> > here's a patch that I think does more or less what Bruno's patch >> > intends to do, against current CVS. >> >> I worked on the same issue. We both use the same pattern >> `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` > > I'd like, if I may, to sound a note of caution concerning this sed > command syntax: the use of semicolons as command separators in the sed > script is an implementation dependent extension, which is not portable. > On some platforms, the test using this sed syntax *will* fail, not > because the feature you are testing is unsupported, but because the test > itself is invalid. > > In November 2005, Robert Goulding posted these bug reports on > groff@gnu.org: > http://lists.gnu.org/archive/html/groff/2005-11/msg4.html > http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html > > It turns out that Robert was having a problem building CVS groff, > which requires texinfo >= 4.8 to compile the info files, under Mac OS X, > and configure was saying his texinfo was too old, in spite of him having > explicitly just installed texinfo-4.8. The actual problem was that the > configure test employed a sed command with this same semicolon usage, > and was not behaving as expected -- the test failed because *it* was > invalid, *not* because the detected texinfo was too old! Is there any evidence that there exists a sed implementation that does not support the semicolon as command separator? Note that the thread you quote above is _not_ about semicolons being unsupported, but rather about missing ones. Autoconf is using semicolons in sed expressions already for many years (eg in the AC_OUTPUT_FILES macro). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: best aclocal include practice wanted
Thomas Porschberg <[EMAIL PROTECTED]> writes: > what is the recommended way to include project-written m4 macros ? Many projects use a directory named m4, but there is no common convention. > I include the macros in /config/m4 > and call in autogen.sh "aclocal -I config/m4" > > The config directory itself is configured in configure.ac > with AC_CONFIG_AUX_DIR(config). This macro is unrelated to the placement of the input files for aclocal. > Is there something wrong with this approach ? No. > What could be done better ? > How should autoreconf find the m4-macros in such a case ? Add this line to the toplevel Makefile.am: ACLOCAL_AMFLAGS = -I config/m4 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: build paths and generated sources
Thomas Porschberg <[EMAIL PROTECTED]> writes: > %.cpp %.h: %.ui > @UIC@ -o $(<:%.ui=%.h) $< > @UIC@ -i $(<:%.ui=%.h) -o $(<:%.ui=%.cpp) $< You should not use $< for constructing targets, only $@ will contain the right name to create. IIUC the commands are creating the each of two targets separately, thus you should use two separate rules: %.h: %.ui @UIC@ -o $@ $< %.cpp: %.h %.ui @UIC@ -o $@ -i $^ This make sure that each comand argument has the correct directory part. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Alternative compiling for debug/optimized code?
"Daniel Kraft" <[EMAIL PROTECTED]> writes: > Using automake the default compiler flags seem to be -g -O2; but most of the > time I don't need debug code You'll need it most when you don't have it. > so I want to disable that -g - option. ./configure CFLAGS=-O2 > And it is possible to do something similiar to the alternative compiling > described above - i.e. to have a simple way for switching opt/debug mode, > maybe > without having to reconfigure? make CFLAGS=-O2 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: shared library from smaller pieces
Vlad Skvortsov <[EMAIL PROTECTED]> writes: > When I use something like this: > > lib_LT_LIBRARIES = libbig.la > libbig_la_LIBADD = .../libaaa.la .../li.la .../libccc.la > > I end up with the shared library that contains _references_ to _shared_ > libraries aaa, bbb and ccc. But I just want their contents to be packed > inside. > > How can I achieve that? Make the small pieces convenience libraries, by using noinst_LTLIBRARIES. *Note (automake)Libtool Convenience Libraries::. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Moving from manual Makefiles to Automake
Paulo Jorge Matos <[EMAIL PROTECTED]> writes: > if g++ -DHAVE_CONFIG_H -I. -I. -I..-I./include -ansi -std=c++98 > -pedantic -Wall -DBUILDDATE=`date +'%Y-%b-%d %R'` -g -O2 -MT ^ You need to quote the output of the command substitution since it contains a space. -DBUILDDATE="`date +'%Y-%b-%d %R'`" Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: AM_FCFLAGS not working as I expect...
Ed Hartnett <[EMAIL PROTECTED]> writes: > What am I missing here? I define the following in my Makefile.am: > > # Point the fortran compiler to current directory. > AM_FFLAGS = -I$(srcdir) > > But no matter what I do, that -I. never appears when the compile > happens: > > f95 -g -O2 -ff2c -c typeSizes.f90 -fPIC -o .libs/typeSizes.o FFLAGS is only used for Fortran 77 compilations. For Fortran 9x compilations FCFLAGS is used. See Fortran 77 Support and Fortran 9x Support in the automake manual. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Defining Macros With Literal Values
Eric Lemings <[EMAIL PROTECTED]> writes: > Greetings, > > I have a tricky little problem I was hoping someone could > help me with. I am trying to write an Autotools macro that > extracts the value of a macro from a system header file > and defines another preprocessor macro with the same value. You can use AC_DEFINE_UNQUOTED to define a macro to the result of a shell substitution. You can easily extract the value from the output of the preprocessor. Don't use the output of a compiled program because that would make cross-compiling impossible. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: configure can not determin 'HAVE_LIMITS'
Ralf Corsepius <[EMAIL PROTECTED]> writes: > limits.h is a POSIX header. On linux it is supplied by GCC. > > So if you want to check for "limits", you should use > AC_CHECK_HEADERS([limits]) > > If this fails, something else is broken and you will have to > investigate. It could be a bug inside of "limits", it could be problem > elsewhere inside of your configure script, or could be a problem with > your include paths. Note that is a C++ header. By default, configure scripts don't use the C++ compiler when checking for headers. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Avoiding installation
John Kodis <[EMAIL PROTECTED]> writes: > I'd like a program to be built when I type "make", but not have it > installed when I type "make install". Is there a provision for this? Use the noinst prefix, like noinst_PROGRAMS. See (automake)Uniform. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Specifying AM_CPPFLAGS from within configure.ac
Jirka Hanika <[EMAIL PROTECTED]> writes:
> For example I'll try to upgrade the "unused variable" warning avoidance
> code to something like
>
> if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");
conftest.c: In function ‘main’:
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: zero-length printf format string
conftest.cc: In function ‘int main(int, char**)’:
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: warning: zero-length printf format string
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: .DELETE_ON_ERROR ?
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello, > I've just stumbled over this problem: > Makefile.am contains: > > foo.h: foo.x > $(GENERATOR) foo.x >foo.h > > But the GENERATOR command failed and I have empty foo.h. Use a temporary file and rename that afterwards. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: F90 vs. F77
Scott Kruger <[EMAIL PROTECTED]> writes: > I am using automake version 1.8.2 This is quite old, the latest version is 1.9.5. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: 5.9 The Future of `aclocal'
Bruce Korb <[EMAIL PROTECTED]> writes: > In fiddling with sharutils, I discovered that it is too early to encourage > the dropping of bootstrap scripts just yet. "autoreconf" does not provide > a way of convincing automake to run with the options, "--gnu" and > "--add-missing". Sure it does. "--gnu" comes from AUTOMAKE_OPTIONS in Makefile.am or from AM_INIT_AUTOMAKE, and "--add-missing" is added with "--install". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: CCing list replies (was: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?)
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > This is not addressed at me, but I also had to learn the hard way > that > - some gnu.org lists but not all automatically exclude subscribers if > they are listed in To: or Cc:. This is customizable, see the mailman options page. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: troubles with conditional install using automake
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hi, > > while I am not able to address your main problem, I'd like to address one > misunderstanding of the make language: > > On Wed, Dec 01, 2004 at 03:29:10PM +0100, Guillaume Rousse wrote: >> initrd_SCRIPTS is defined to $(INITRD) at the beginning of the Makefile, >> while INITRD is defined at the end of the Makefile, with other >> conditional variables, and thus appears empty when it is evaluated. > > No, make doesn't work this way; consider the makefile: > > A = $(BB) > > e: > echo $(A) > > BB=x > > > Then ``make'' runs ``echo x'' But when $(A) appears on the dependency list of e, for example, it will be expanded already while the makefile is being read in. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Error because README is missing
"Paul D. Smith" <[EMAIL PROTECTED]> writes: > However, I actually had a second error that I didn't mention because I > figured it would be the same problem... but it's not. > > The second error is this: > > $ automake --add-missing --no-force > configure.in:398: required file `build.sh.in' not found > > This file is being created with this in my configure.in file: > > if test -f $srcdir/build.sh.in; then > AC_CONFIG_FILES(build.sh) > fi AC_CONFIG_FILES is a declaration-like macro, you can't execute it conditionallyon the shell level. If you want to make it conditional on the existence of the input file you need to do that on the m4 level. Untested code ahead. m4_syscmd([test -f build.sh.in])dnl m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Disabling optimization
"Thomas 'Tom' R. Treadway III" <[EMAIL PROTECTED]> writes: > CXXFLAGS="`echo $CXXFLAGS | sed -e 's|-O2||'`" This assumes that CXXFLAGS does not contain "-frob-O2any". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Disabling optimization
Stepan Kasal <[EMAIL PROTECTED]> writes:
> out of curiosity, what would be wrong with the following?
>
> if test -n "${CXXFLAGS}"; then
> CXXFLAGS="-g"
> fi
> AC_PROG_CXX
I think you got it backwards. This makes it impossible to override
CXXFLAGS.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Feature request
Albert Chin <[EMAIL PROTECTED]> writes: > When building software with installable .m4 files (libtool, pkgconfig, > gtk+, etc.), if each software program is installed to a separate > directory, aclocal must be used like so: > $ aclocal -I [path to libtool .m4 files] \ > -I [path to pkgconfig .m4 files] ... > > How about an environment variable that aclocal would query that does > the job of -I? pkgconfig uses the PKG_CONFIG_PATH variable giving > locations for pkg-config to query for .pc files. Doing something > similar with aclocal would make automating use of aclocal in build > scripts much easier. Put the options in ACLOCAL_AMFLAGS in the toplevel Makefile.am and autoreconf will take care of everything. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Linked/Shared Librairies
Xavier Décoret <[EMAIL PROTECTED]> writes: > First question: I would like the libmytools.so to be linked with the > libbase.a so that I can distribute this .so alone without distributing > libbase.so (yes, there is a good reason for doing so ;-)). How can I do > this? I think you want to use noinst_LTLIBRARIES for libbase.la. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: two binaries with different libraries
Frederik Fouvry <[EMAIL PROTECTED]> writes: > Thanks, that's working very nicely. A problem is however that > autoheader is not detecting the library checks anymore for > config.h.in. I have calls like these in configure.ac: > > AC_CHECK_LIB([itsdb], [main], [cat >>confdefs.h <<_ACEOF > #define HAVE_LIBITSDB 1 > _ACEOF > LIBITSDB=-litsdb]) What's wrong with AC_DEFINE? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: two binaries with different libraries
Frederik Fouvry <[EMAIL PROTECTED]> writes: > - I use *_LDADD. In that case, as far as I know, I cannot check > for the libraries in the configuration anymore. Is it sensible > to add AC_SUBST(program_LDADD) in configure.ac? Let autoconf define and substitute a variable for each library to be checked for and use the appropriate @LIBFOO@ in the definition for each program_LDADD. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: distcheck bug
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>eval isset=$\{`echo $var`'+set'\}
This is equivalent to
eval isset=\${$var+set}
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Is it a bug with the latest AUTOMAKE?
Avneet Chhabra <[EMAIL PROTECTED]> writes: > Does someone on this list help and know the correct > answer? Please try autoreconf. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: automake for plugins (no PROGRAMS, no LIBRARIES)
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes: >>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"). Use libtool with -module. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: disable -g flag
JRBCAST <[EMAIL PROTECTED]> writes: > Hi, > > I have been trying to disable the -g flag that autoconf uses when > compiling my GNU project. I have tried --enable-debug=no --disable-debug > and none works. I have had a look at google and some questions but no > response... > > Can you help me? $ ./configure CFLAGS=whatever-you-want Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: CVS access broken???
Mark Phillips <[EMAIL PROTECTED]> writes: > Hi there, > > I am currently trying to debug a problem with automake 1.8.2 and I can't > get CVS to work. > > Both the following fail:- > > 1) http://savannah.gnu.org/cgi-bin/viewcvs/automake/ > >Gives "automake - this entry is unreadable" > > 2) cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/automake co automake automake is not hosted on savannah, but on sourceware. :pserver:[EMAIL PROTECTED]:/cvs/automake Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Extra recursive targets
Is there a way to add additional recursive targets to a makefile? I tried to use RECURSIVE_TARGETS += foo-recursive but automake complains about the use of `+='. When changing that to a simple `=' the generated makefile has only foo-recursive as RECURSIVE_TARGETS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: AM_INIT_AUTOMAKE Call in Automake 1.7
"Drummonds, Scott B" <[EMAIL PROTECTED]> writes: > Actually, I guess my original post wasn't complete. I had successfully > rerun aclocal before generating this error message. This version of > aclocal, from the same Automake installation directory, reports itself > as "aclocal (GNU Automake) 1.7". > > So, I do believe that this error is occuring because of configure.in. You might also have some old macros in acinclude.m4, or in some other *.m4 file in a directory that is searched by aclocal due to a -I option. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: installing headers files in /usr/local/include...
Eric Tchepannou <[EMAIL PROTECTED]> writes: > Thanks Adreas, > > What about if my headers should be in /usr/local/include/myapp ? Don't toppost. > cheers > > On Wednesday 11 February 2004 15:22, you wrote: >> Eric Tchepannou <[EMAIL PROTECTED]> writes: >> > Hello all, >> > >> > I have written (I am still writing actually) an application and use >> > automake/autoconf. I would like to have my headers to be installed under >> > /usr/local/include when applying make install. >> > I wonder if someone can help me how to reach this with automake. >> >> include_HEADERS = >> >> Andreas. *Note (automake)Install::. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: installing headers files in /usr/local/include...
Eric Tchepannou <[EMAIL PROTECTED]> writes: > Hello all, > > I have written (I am still writing actually) an application and use > automake/autoconf. I would like to have my headers to be installed under > /usr/local/include when applying make install. > I wonder if someone can help me how to reach this with automake. include_HEADERS = .... Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: AM_AUTOCONF does not work?
Jose Roman Bilbao <[EMAIL PROTECTED]> writes: > Hi, > > Can anybody tell my why this code is not substituting the variable > WITH_OPENGL in my automake.am and how should I write it to work? > > MDL_HAVE_OPENGL > > AM_CONDITIONAL( WITH_OPENGL, test -n $GL_FLAGS) > #AM_CONDITIONAL( WITH_OPENGL, test -n $GL_LIBS) You need to fix the quoting. AM_CONDITIONAL( WITH_OPENGL, test -n "$GL_FLAGS") #AM_CONDITIONAL( WITH_OPENGL, test -n "$GL_LIBS") Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: about requiring Perl 5.6 in Automake 1.9
Bruce Korb <[EMAIL PROTECTED]> writes: > Alexandre Duret-Lutz wrote: > >> Is there any reason why this would be a very bad idea? > > It is inconsistent? The auto* tools (viz. autoconf) still > assumes a shell that has no functions. This makes the config > script incredibly larger and slower than necessary. That > annoys me greatly, far beyond this wart. Lobby for that change > first!! The configure script will be run on the user's system, whereas automake runs on the developer's system. You can expect that a developer upgrades his system from time to time, but you still want to be able to configure and build a package on an old system. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: RFC: doc for `Handling Tools that Produce Many Outputs'
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> Thanks for all your comments (public and private)!
>
>>>> "Eric" == Eric Siegerman <[EMAIL PROTECTED]> writes:
>
> Eric> On Sat, Jan 31, 2004 at 11:28:29PM +0100, Alexandre Duret-Lutz wrote:
> >> One of the output (here `data.c') is used as a witness of the run of
> >> `foo'. [...]
>
> Eric> Hmm. I understand what you're saying here, but "witness" seems
> Eric> an odd choice of words to say it. I can't think of a better one
> Eric> offhand, though. What's the French word you're trying to
> Eric> translate?
>
> témoin = { witness, indicator, evidence }
>
> Perhaps evidence is better?
IMHO, indicator would be best.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: include_HEADERS and all-am
[EMAIL PROTECTED] writes: > Given my Makefile.am: > > AM_CPPFLAGS = -I$(srcdir)/../inc > lib_LIBRARIES = libtest.a > libtest_a_SOURCES = test.cpp test.hpp > > This works fine. > > Now I add to the end of that: > include_HEADERS = test.hpp > > Now I get a make error: > > make[2]: *** No rule to make target 'test.hpp', needed by `all-am'. > Stop. Try moving include_HEADERS into ../inc/Makefile.am. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal-1.8/m4_include behaving oddly
Phil Edwards <[EMAIL PROTECTED]> writes: > On Mon, Dec 22, 2003 at 03:17:54PM +0100, Andreas Schwab wrote: >> Phil Edwards <[EMAIL PROTECTED]> writes: >> > We have tried very hard to avoid requiring developers to pass arguments >> > to the various autotools, largely because there's no way to help them do >> > so automatically. >> >> What's wrong with "ACLOCAL_AMFLAGS = -I .." in Makefile.am? > > Does aclocal pick those out itself, or is that only when rerunning from > a previously-built objdir? aclocal itself does not pick it up, but autoreconf does, and the makefile rules generated by automake do. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: autom4te.cache and Automake 1.8
FrÃdÃric L. W. Meunier <[EMAIL PROTECTED]> writes: > The info page for Autoconf contains: > >As an example, to disable Autoconf caches (`autom4te.cache') > globally, include the following lines in `~/.autom4te.cfg': > > > ## -- ## > ## User Preferences. ## > ## -- ## > > begin-language: "Autoconf" > args: --no-cache > end-language: "Autoconf" > > > I've been using it for a long time, but it no longer works with > Automake 1.8 and Autoconf 2.59, but works with Automake 1.7.9 > and the same Autoconf. aclocal uses the language "Autoconf-without-aclocal-m4". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal-1.8/m4_include behaving oddly
Phil Edwards <[EMAIL PROTECTED]> writes: > One of the GCC runtime libraries (libstdc++-v3) has for years contained > the following lines in acinclude.m4: > > m4_include([../libtool.m4]) > dnl The lines below arrange for aclocal not to bring an installed > dnl libtool.m4 into aclocal.m4, while still arranging for automake to > dnl add a definition of LIBTOOL to Makefile.in. > ifelse(,,,[AC_SUBST(LIBTOOL) > AC_DEFUN([AM_PROG_LIBTOOL]) > AC_DEFUN([AC_LIBTOOL_DLOPEN]) > AC_DEFUN([AC_PROG_LD]) > ]) > > I've been content to ignore them, since I don't understand libtool. > But now we're trying to move to the latest released tools, and aclocal > 1.8 flags errors dealing with that block: > > aclocal: macro `_AC_PROG_LIBTOOL' required but not defined > aclocal: macro `_AC_LIBTOOL_CXX' required but not defined > aclocal: macro `_AC_LIBTOOL_GCJ' required but not defined Which means that you don't have libtool.m4 in $datadir/aclocal. > On the advice of a colleague, I tried adding "-I .." to the command line. > This worked. Previous versions of aclocal also required this. If you run aclocal 1.7.x with --verbose you will see that it never looks at ../libtool.m4 unless you pass "-I ..". > Unless I'm missing some important piece of philosophy, this is also very very > poor behavior. We've specifically *told* autowhatever to get a file from > ".." and it's definitely doing something with that file (moving it away > leads to file-not-found errors). But the definitions inside are somehow > being ignored, unless we futz with redundant command line options. aclocal has never looked at (m4_|s)include while collecting files for scanning. > We have tried very hard to avoid requiring developers to pass arguments > to the various autotools, largely because there's no way to help them do > so automatically. What's wrong with "ACLOCAL_AMFLAGS = -I .." in Makefile.am? > And just recently I've been factoring out pieces of our large > acinclude.m4 into various smaller .m4 files; if the behavior of > m4_include is suddenly different, we'll have to rethink all that. There was no change in behaviour. It only worked before because you had the libtool macros installed in $datadir/aclocal. Presumably you are using a different prefix for your automake 1.8 installation, so that $datadir/aclocal is empty or does not exist. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal 1.8 no longer loads overridden macros
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > You might try a CVS version of GNU m4... from the ChangeLog: > > 2001-10-10 Gary V. Vaughan <[EMAIL PROTECTED]> > > ~The trace semantics now attach the trace bit to a symbol name. > ~For as long as a traceon(`foo') is active, calls to foo will be > ~traced regardless of intervening undefines or module unloads. > > In anticipation of your next question: When will it be released? :-) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal 1.8 no longer loads overridden macros
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > I think we can't do anything about this in aclocal, apart from > documenting this new incompatibility. Since we are obviously > relying on --trace more and more, maybe we should prohibit all > macros that can affect the trace attribute. I agree. > Is undefine() the sole such macro, or are there others? traceoff(), obviously, but otherwise those two seem to be the only ones. > Are there cases where undefine() is needed? It seems > superfluous in m4/search-libs.m4. Yes, looks like. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal 1.8 no longer loads overridden macros
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: >>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: > > Andreas> With aclocal 1.8 you no longer get overridden standard > Andreas> autoconf macros loaded from local *.m4 files. > > I could not reproduce this (tried to redefine AC_PROG_CC > successfully). Can you send detailed instructions? Here is a testcase: $ cat configure.ac AC_INIT([aclocal-test], [0]) AC_PROG_CC AC_OUTPUT $ cat prog-cc.m4 undefine([AC_PROG_CC]) AC_DEFUN([AC_PROG_CC], [echo [AC_PROG_CC] dummy]) $ aclocal -I . $ cat aclocal.m4 cat: aclocal.m4: No such file or directory The problem is caused by the call to undefine, this loses the traced attribute. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: aclocal 1.8 no longer loads overridden macros
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: >>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: > > Andreas> With aclocal 1.8 you no longer get overridden standard > Andreas> autoconf macros loaded from local *.m4 files. > > I could not reproduce this (tried to redefine AC_PROG_CC > successfully). Can you send detailed instructions? I can't reproduce it with a simple test case either, but running "aclocal -I m4" in the coreutils-5.0 source directory does not include the file m4/search-libs.m4 in aclocal.m4. I have no idea why the coreutils macros behave differently. The output of the autom4te call inside aclocal in any case does not include AC_SEARCH_LIBS, although it is called by jm_FUNC_NANOSLEEP, which _is_ included. Trying to investigate... Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, MaxfeldstraÃe 5, 90409 NÃrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
aclocal 1.8 no longer loads overridden macros
With aclocal 1.8 you no longer get overridden standard autoconf macros loaded from local *.m4 files. Presumably this is because autom4te always looks in autoconf/autoconf.m4f first, thus the file that contains the replacement for a standard macro is not considered for this macro any more. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: autoreconf --flavor ?
Patrick Guio <[EMAIL PROTECTED]> writes: |> Dear all, |> I am using currently autoconf 2.57 and automake 1.7.2. |> I find it annoying not to be able to use te nice tool autoreconf without |> that all the following files NEWS, README, AUTHORS and ChangeLog should be |> present in the current directory. automake has the possibility to disable |> that feature with the --foreign option. Why not allow autoreconf to take |> in options for the other tools? Try setting it via AUTOMAKE_OPTIONS in Makefile.am or AM_INIT_AUTOMAKE in configure.in. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: auto-regenerating Makefile.in and Makefile files
Akim Demaille <[EMAIL PROTECTED]> writes: |> >>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: |> Tom> We could just always run `./config.status' and rebuild |> Tom> everything. We've always avoided that on performance and |> Tom> historical grounds. |> |> We can add --update to config.status, so that it only recreates its |> obsolete offsprings. Would that help Automake? IMHO, now that config.status is much faster than it used to be performance has become nearly a non-issue. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: auto-regenerating Makefile.in and Makefile files
Tom Tromey <[EMAIL PROTECTED]> writes: |> >>>>> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: |> |> Earnie> Wouldn't this work anyway because you had to change the |> Earnie> top-level Makefile.am or configure.in to include the new |> Earnie> SUBDIR? I.E.: Makefile.in : Makefile.am configure.in |> |> The problem is that the Makefile always runs config.status to recreate |> just a single Makefile (the current one). The question is: what |> Makefile decides to generate the new Makefile for the first time? |> Or, for that matter, the new Makefile.in? There is none. You need to re-run configure when a new makefile is added (you can use ./config.status --recheck && ./config.status for that). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH]: ld/Makefile.am
Ian Lance Taylor <[EMAIL PROTECTED]> writes: |> I'm still surprised by something here. The error message which |> H.J. cites is from libiberty/pexecute.c. That means that the exec |> which should start the shell script is failing. The case is precisely |> identical from the point of view of gcc, and the shell script is never |> actually executed. That means that somewhere inside the kernel, when |> it tries to execute the shell script, it is running out of memory. |> |> Executing a shell script does use a bit more memory, but only just |> enough for "/bin/sh" and the name of the script to execute. If that |> is pushing H.J. over the memory limit, then he must have been |> extremely close to that limit to start with. It's not only this but also some additional --rpath options, which can carry along long file names. Those are only passed when the lt-ld-new binary is linked, which could account for the push beyond the limit. |> For that matter, I actually didn't think that the Linux kernel had an |> argument size limit. It has. It is defined by MAX_ARG_PAGES (== 32, ie. 128kB w/4KB pages). And remember that this includes the environment as well. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Re: [PATCH]: ld/Makefile.am
Ian Lance Taylor <[EMAIL PROTECTED]> writes: |>Date: Thu, 9 Mar 2000 11:50:59 -0800 |>From: "H . J . Lu" <[EMAIL PROTECTED]> |> |>I know this patch doesn't look very clean. But I don't know automake |>well enough to make it better. Here is the problem I am trying to fix. |>I got: |> |># /work/ia64/bin/cygnus/2303/gcc/xgcc |-B/usr/ia64-cygnus-linux/ia64-cygnus-linux/bin/ |-B/usr/ia64-cygnus-linux/ia64-cygnus-linux/lib/ -B/work/ia64/bin/cygnus/2303/gcc/ |-g -O2 -pipe -Dno_inhibit_libc -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates |-fexceptions -Wl,-soname,libstdc++-libc6.1-2.so.3 -shared -o |libstdc++-3-libc6.1-2-2.10-ia64-000216.so `cat piclist` -lm |>gcc: installation problem, cannot exec |>`/work/ia64/bin/cygnus/2303/gcc/collect2': Argument list too long |> |>What happened were |> |>1. I built as, ld, gcc, and libstdc++ together. |>2. I enabled shared libbfd. |> |>As the result, ./ld/ld-new, which is a shell script, uses too many |>arguments when it was executed the first time. The first time when |>you run ./ld/ld-new, it creates .libs/lt-lt-ld-new if shared libbfd |>is enabled. After that, everything seems ok. I am trying to add a |>rule to ld/Makefile.am such that we will run ./ld/ld-new just once |>after it is built. I don't care if it really works or not. The idea |>is to create .libs/lt-lt-ld-new if necessary. However, I couldn't |>find a clean way to do so with automake. Any suggestions? |> |> This sounds like a libtool bug. Why fix it in binutils or automake? |> Whatever it is ld-new does the first time it is run, why doesn't |> libtool do that when it creates ld-new? Because the executable that libtool creates (.libs/ld-new) is meant to be installed, but when you want to run it in the build directory you want to make sure that it finds the shared libraries in the build directory, not the ones that may be installed earlier. To achieve this, libtool relinks the binary with a special set of --rpath options pointing into the build directory. This is done everytime the actual binary is rebuilt. There is an option to libtool (--disable-fast-install) that tells it to do the relinking at install time, and the binary in the build directory is built with the appropriate --rpath options in the first place. All this is required because --rpath has precedence over LD_LIBRARY_PATH. On systems were it doesn't libtool just uses LD_LIBRARY_PATH to achieve the same effect. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
