H=${ACLOCAL_PATH}:/usr/local/share/aclocal:
> +test -d /usr/share/aclocal && \
> +ACLOCAL_PATH=${ACLOCAL_PATH}:/usr/share/aclocal:
> +ACLOCAL_PATH=${ACLOCAL_PATH%:}
>
> ${AUTORECONF} -i -v "$@"
>
--
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!
Bert Wesarg writes:
We have such a summary framework in our Score-P [1] project. Which
also has nested configures. It collects all config.summary at the end
into the $PACKAGE.summary file, which can than also be installed for
later inspection.
Thanks!
I put up the M4 file file here [2]. If
big
autoconf macro file, and that file is not well indented.
Is there a good autoconf mode out there that will help me make sure the
autoconf macros are properly indented?
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member
Eric Blake writes:
On 02/13/2015 01:35 AM, Harlan Stenn wrote:
Is there a good autoconf mode out there that will help me make sure
the autoconf macros are properly indented?
Not that I'm aware of, but if you find one, be sure to post a link to
it back here (the emacs file
Gavin Smith writes:
What is wrong with
--prefix=/usr/local --sysconfdir=/etc
With
prefix=@prefix@
sysconfdir=@sysconfdir@
datarootdir=@datarootdir@
includedir=@includedir@
localstatedir=@localstatedir@
sharedstatedir=@sharedstatedir@
in Makefile.in, and
AC_INIT
Eric Blake writes:
On 11/16/2014 11:51 PM, Harlan Stenn wrote:
One installation directory choice I haven't found a good solution to
is the ntp.conf file, which is traditionally installed in /etc/ . If
there is an ntp.keys file, it will usually go in /etc/ as well.
In general, folks want
about using ntpconfdir for this, but how to make that work
the way the other paths do hasn't been obvious to me from casual study.
I'd rather not use AC_ARG_ENABLE or AC_ARG_WITH for this, either, just
because that seems crufty to me.
What other choices are there?
--
Harlan Stenn st...@ntp.org
http
speedup in the configure time, as
we have a growing number of buildbot targets and we plan to do both
scratch builds as well as upgrade (with autoconf cache) builds as part
of our build/test process.
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member
Adding automake to the list, as with the information below this is now
looking like an automake issue.
I rolled another release and here's what I see:
harlan@hms-mbp11% ls -ltrT config.h.in sntp/config.h.in aclocal.m4
sntp/aclocal.m4 sntp/m4/version.m4
-rw-rw-r-- 1 harlan wheel 40 Feb 23
Hi Peter,
Peter Johansson writes:
On 02/27/2014 04:47 AM, Harlan Stenn wrote:
So while the filestamps are technically correct, the generated
Makefile *will* see that version.m4 is newer than config.h.in and
regenerate it via Makefile dependencies.
I suspect the answer is that at the end
Patrick Welche writes:
On Sat, Feb 22, 2014 at 07:47:36AM +, Harlan Stenn wrote:
But apparently something strange is going on, because after we run the
bootstrap script, if we run make we see:
...
Prerequisite `../version.m4' is newer than target `../config.h.in
missing something.
I'm continuing to dig into this, and if anybody has any ideas I'd love
to hear them.
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org
Peter Rosin writes:
[Technically this is a Libtool question, but I'll answer here anyway]
...
The last thing LT_PATH_LD does is to expand _LT_PATH_LD_GNU, which runs the
linker with -v and looks for GNU or with BFD in the output and assumes
GNU ld if that is found. The result is stored in
, as it must be in the executable early
enough; if we drop privileges it's too late to call dlopen(). That's
not entirely accurate, but it's close enough.
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
___
Autoconf mailing
this? Are there better options?
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Gavin Smith writes:
On Mon, Sep 30, 2013 at 8:56 AM, Harlan Stenn st...@ntp.org wrote:
I've got a situation where I want to track specific libraries that are
needed for building specific programs. Sometimes this is for things
like openssl and sometimes it's network stuf or thread stuff
Bob Friesenhahn writes:
On Thu, 20 Jun 2013, 'Chris Hall' wrote:
Of course gcc gives __BIGGEST_ALIGNMENT__ for this. And I guess
other compilers do something similar...
...but I cannot help feeling that autoconf should cover this, but
if it does, I have failed to find where :-(
How
Paul Eggert writes:
On 10/27/2012 01:38 PM, Roger Leigh wrote:
Is anyone working on such a thing?
Not that I know of.
For C, we're deprecating the I want version X
macros in favor of just AC_PROG_CC_STDC, which says
I want the latest version. You might want to do
that for C++ to, as
Adrian Bunk writes:
On Sat, Oct 27, 2012 at 02:05:01PM -0700, Harlan Stenn wrote:
Paul Eggert writes:
For C, we're deprecating the I want version X
macros in favor of just AC_PROG_CC_STDC, which says
I want the latest version. You might want to do
that for C++ to, as it's more
Adrian Bunk writes:
On Sat, Oct 27, 2012 at 10:47:50PM +0100, Roger Leigh wrote:
Maybe have an optional argument to AC_PROG_CC_STDC to select
the standard e.g.
AC_PROG_CC_STDC([C99])
?
I like this idea.
Latest discussion result was that there is no downside of setting the
compiler
Adrian,
I don't think either one of us will convince the other.
I'm done.
H
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Adrian Bunk writes:
On Sat, Oct 27, 2012 at 05:59:23PM -0700, Harlan Stenn wrote:
Adrian,
Hi Harlan,
I don't think either one of us will convince the other.
I'm done.
I'm surprised getting that as an answer to an email where I suggested a
possible solution for your use cases
Just off the top of my head, what about an AC_GCC_FILTER_WERROR macro
that would search for an incoming -Werror and remove it if it was
provided and restore it at the end?
The downside of this is that maintainers would still have to know to add
it.
And I recall seeing a number of stable GNU
Miles wrote:
Hmm, OK, so in that case, does anybody know what typical practice for
FreeBSD users is (so I can be sure to cater to it)? They must
encounter this issue all the time.
Do they usually just specify CFLAGS/CPPFLAGS/LDFLAGS on the configure
command line [maybe via a local
Eric wrote:
Instead of 'rm -f $list', you have to use
'test -n $list || rm -f $list'.
This may also not be an issue any longer, but (many) years ago I learned
(probably from Larry Wall) to avoid using 'test -n ...' when possible,
as it was too often *not* a shell builtin and therefore was a
Eric wrote:
On 06/20/2011 04:26 PM, Harlan Stenn wrote:
I have the need (or at least a strong desire) to run config.guess
(and therefore config.sub) from some scripts that I invoke from
inside 'configure'.
I'm noticing that the current directory seems to be the srcdir if I
put this code
also aware that some folks may have shell RC files that will re-set
the PATH when a subshell is spawned, which makes this all even trickier.
I'm looking for a good solution here.
Suggestions?
--
Harlan Stenn st...@ntp.org
http://ntpforum.isc.org - be a member
involved that what you might
need.
--
Harlan Stenn st...@ntp.org
http://ntpforum.isc.org - be a member!
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
A quick hack (and it may not work well) would be to detect these
systems, and stuff in something that effectively does '#define fork
vfork'.
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Stefano wrote:
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
And I now have a case where I think I want to pass in a CPPFLAGS entry
to a subpackage, based on stuff that the parent configure knows.
So I'm thinking about:
AC_CONFIG_SUBDIRS([foo], [--with-zardoz CPPFLAGS=-Isomething])
Not sure
Ralf wrote:
* Harlan Stenn wrote on Fri, Apr 01, 2011 at 09:04:09AM CEST:
Not sure if this is a great idea or not, but the only other alternative
I can think of is to modify the configure.ac in the subpackage, and I
would rather not do that as it creates extra work when I go to upgrade
Ralf wrote:
* Harlan Stenn wrote on Fri, Apr 01, 2011 at 09:41:33AM CEST:
Ralf wrote:
The trick is: you adjust the flags in subpkg/configure.gnu, then call
subpkg/configure with them. The subpkg/configure.gnu file might
actually belong to the toplevel package. A hack, but fairly easy
Stefano wrote:
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
AC_CONFIG_SUBDIRS([bar], [--without-zardoz])
I think this might be a wonderful idea. I haven't looked at it much,
but it has potential. We might well need/use something like this for NTP.
I can't easily look right now, though.
It
Karl wrote:
I fully recognize that people are still running Solaris 7 (and probably
older versions) on mission-critical and other systems. But, how many of
those systems are (a) installing brand-new GNU packages (which
presumably wouldn't be happening on mission-critical systems) *and*
(b)
Tim,
In your case how would you detect if a .c file was grabbing the wrong
config.h file?
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
NTP does a fair amount of providing missing library code as well - we
generally only use a package-provided copy if one is not availble from
the system.
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
going on with 2.59, 2.61, and 2.64.
--
Harlan Stenn st...@ntp.org
http://ntpforum.isc.org - be a member!
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Hi Ralf,
* Harlan Stenn wrote on Tue, Oct 27, 2009 at 12:39:24AM CET:
Does anybody have (a pointer to) a small utility that will return a list
of available C compilers on a system?
I guess you can peek at AC_PROG_CC for a list, that is of course far
from complete.
Extra points
Thanks a bunch, Ralf.
If I get something working I'll post about it.
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Rainer wrote:
Calling a program arm-unknown-linux-gcc isn't particularly
useful. Especially if there are two arm-unknown-linux-gcc's which are
quite different, each of them needed for a particular
cross-compilation environment on the same machine.
Have you seen any of my postings to this
As far as I'm concerned, the *only* thing I expect from config.guess is
to return me a CPU-VENDOR-OS triple.
And with (braindamaged, IMO) return values like i686-pc-linux-gnu, I
have my own wrapper (that calls config.guess and does various other
probing) that I use when I really need a CVO
autoconf on the beast, and then
another significant amount of time to run the resulting 'configure'
script and make sure it did the right thing.
Anybody have any suggestions on how I can do this as quickly and
painlessly as possible?
--
Harlan Stenn [EMAIL PROTECTED]
http://ntpforum.isc.org
Good news - the smaller configure.ac that exhibits this problem is under
400 lines long...
I've cleaned up almost all of the possible quoting problems and I'm
still seeing the issue.
I'll keep digging...
H
___
Autoconf mailing list
Autoconf@gnu.org
Hi Ralf,
Ralf wrote:
Hi Harlan,
* Harlan Stenn wrote on Sat, Sep 13, 2008 at 05:23:41AM CEST:
I wrote:
PATH_NET_SNMP_CONFIG=whatever
AC_PATH_PROG([PATH_NET_SNMP_CONFIG], [$PATH_NET_SNMP_CONFIG])
and that doesn't work (with autoconf 2.59).
What doesn't work
])
and that doesn't work (with autoconf 2.59).
I'll keep digging, and if anybody has a suggestion I'd love to hear it.
--
Harlan Stenn [EMAIL PROTECTED]
http://ntpforum.isc.org - be a member!
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org
I wrote:
So what's the secret to using a (shell) variable for the 2nd arg in
AC_PATH_PROG? I want the user to be able to override the default name,
as it may be suffixed by -32 or -64...
I've tried using:
PATH_NET_SNMP_CONFIG=whatever
AC_PATH_PROG([PATH_NET_SNMP_CONFIG],
Matej,
Some of us strongly prefer top-posting. Others hate it. When in
Rome...
(I think the answer is to have a new type of encapsulated email response
if one is not using interspersed reply - the client mail reader will
put the response where the reader prefers. In this case I'll have my
In bin/Makefile.am you want:
foo_SOURCES = foo.c
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Peter O'Gorman wrote:
Josef noted that he did not want this to change. I'm inclined to agree
with him, people who are cross-compiling may not have all of the `tools'
available as triplet-prefixed-name, but are likely to have their PATH
set correctly to point at the cross-tools.
I've
Bob Rossi wrote:
On Tue, Sep 02, 2008 at 06:12:13PM +, Harlan Stenn wrote:
I've used cross-compiles (off and on) for years and I gotta say the
first time I got this message I probably did some pissing and moaning.
But I do believe that proper naming is the way to go.
Then I created
Ralf Wildenhues wrote:
This ignores the fact that some users get this warning not because they
are using unprefixed tools, but rather because they are using compiler
wrappers like mpicc, mpxlc etc. And they may not even really do cross
compiling, it may just be that their system consists of
Does anybpdy have a macro for seeing if ntp-snmp-config exists, and then
running it to get the values of various *FLAGS and libraries? While I'm
on my wishlist, it would be swell if this marco supported cross-compiles.
--
Harlan Stenn [EMAIL PROTECTED]
http://ntpforum.isc.org - be a member
John wrote:
For example, on Solaris SPARC hosts, you can target sparc-generic code,
if you wish, but it makes no sense to even see an option,
--enable-sparc-generic on an Intel Linux box.
It makes sense if you are cross-compiling.
As I recall, the recommended behavior is to ignore unknown
Ralf wrote:
* Harlan Stenn wrote on Mon, Jun 23, 2008 at 07:31:17PM CEST:
As I recall, the recommended behavior is to ignore unknown --with[out]-*
and --[dis]enable-* flags, as a top-level configure script may be
calling more than one subordinate configure scripts.
Autoconf 2.62 warns
Paul wrote:
Eric Blake [EMAIL PROTECTED] writes:
2008-06-09 Eric Blake [EMAIL PROTECTED]
+ Mark AC_TYPE_SIGNAL as obsolete.
Thanks for doing this; it makes sense to me. Signal handlers
returning 'int' became obsolete on all C platforms as of the first C
standard in 1989. In
Paul wrote:
Eric Blake [EMAIL PROTECTED] writes:
2008-06-09 Eric Blake [EMAIL PROTECTED]
+ Mark AC_TYPE_SIGNAL as obsolete.
Thanks for doing this; it makes sense to me. Signal handlers
returning 'int' became obsolete on all C platforms as of the first C
standard in 1989. In
Eric Blake wrote:
According to Bob Friesenhahn on 4/9/2008 12:35 PM:
| I am confused since I don't see how the usefullness of this test can be
| obsolescent.
The test was merely whether compilers support the type 'long double'; as
all modern compilers obey this part of the C standard, it is
Eric Blake wrote:
Harlan Stenn stenn at ntp.org writes:
A bunch of stuff
... (T)here are platforms that do indeed have 'long double', but where
it is not wider than 'double' - should HAVE_LONG_DOUBLE be defined or
not?
IMO, yes. If folks care about the actual size we have SIZEOF_ things
Peter Boyle wrote:
Mine is one of a class of apps that regularly use autoconf
in parallel computer codes. These by nature are often cross
tools, and frequently use vendor supplied wrappers like mpicxx as CXX
etc to sort out the libraries compile environment...
I recommend you create
I have not put enough thought into the following.
A variety of problems can crop up if one is doing things in an
NFS-mounted filesystem and there is clock skew between the local machine
(NFS client box) and the machine that hosts the actual filesystem (NFS
server box).
I am thinking there may
Bob Friesenhahn wrote:
On Wed, 21 Nov 2007, Harlan Stenn wrote:
A variety of problems can crop up if one is doing things in an
NFS-mounted filesystem and there is clock skew between the local machine
(NFS client box) and the machine that hosts the actual filesystem (NFS
server box
Bob Friesenhahn wrote:
On Thu, 22 Nov 2007, Harlan Stenn wrote:
I *think* I'd be happy with 'clock skew in the build directory'.
You mean like
CPU -- NFS (Sources + Objects)
This is one case I know I care about.
or
NFS1 (Sources)
/
CPU
\
NFS2
Bob,
Bob Proulx wrote:
find . -type f -print0 | xargs -r0 touch --reference .
make clean
make
That was cut from an old saved message. I will update it to the
current find use avoiding the -print0 and say that I should have said
this instead:
find . -type f -exec touch
Andreas wrote:
Harlan Stenn [EMAIL PROTECTED] writes:
Bob Proulx wrote:
find . -type f -exec touch --reference . {} +
I thought xargs was *significantly* faster than exec.
Note the trailing '+'. This makes it essentially equivalent to the
above use with xargs, and even faster than
Is there a configure option to tell libtool to generate
sys_lib_search_path_spec using i386 instead of x86_64? Below is
a clip of ./libtool --config output.
I am trying to build 32bit binaries on x86_64 architecture.
This sounds to me a lot like a cross-compile case.
You are build machine
This is the first I've seen on this thread.
I have heard that GPLv3 is viral/invasive.
The short question I have is:
If automake/autoconf use GPLv3, will I be able to use them for packages
that are NOT GPLv3?
IE, if GPLv3 is viral/invasive, I cannot use software covered by GPLv3
for most of
Eric,
Sounds good - thanks very much!
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Hi Ralf,
So AFAICS the only reason that kept this patch from being applied was
that it was lacking a ChangeLog entry, NEWS and documentation update.
And a name to attach to the change.
I'll put it on my list unless you're raising your hand wildly now...
(more on automake-patches)
I've
Hi Ralf,
Sorry - this really should have been [EMAIL PROTECTED]
The link you requested is:
http://lists.gnu.org/archive/html/automake-patches/2002-07/msg00141.html
Thanks...
H
___
Autoconf mailing list
Autoconf@gnu.org
Hey,
Hi! I write to you directly because I have a problem that, searching
through Google, you posted to the autoconf mailing list with the same
problem...but the solution itself was not posted.
OK, and I'm adding autoconf@gnu.org to my response.
You had a problem in which you had to run
I've got a test in a configure script that runs like this:
...
checking for MD5Init
gcc -o conftest -g -O2 -Wall -Wcast-qual -Wmissing-prototypes -Wpointer-arith
-Wshadow -Wstrict-prototypes conftest.c -lmd5 -lelf 5
conftest.c:51: warning: function declaration isn't a prototype
test -x / { { test -x /bin/sh test ! -f /bin/sh.exe; } || test ! -f
/bin/sh; }
Are curly braces safe to use on Old versions of /bin/sh?
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
David,
Just a guess here. What are the ownership/perms of the autom4te.cache
dir and the /requests file in there?
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
* Bob Friesenhahn [EMAIL PROTECTED] [2007-03-05 09:17:27 -0600=
]:
I can't imagine why one would want to use a non-standard,=20
non-portable, function like daemon().
=20
True. I suppose I can always code one myself a la Stevens UNP Vol 1.
Because different OSes need slightly
I think the thing to do is a) include both headers and be done with it or
b) code a small daemon function myself given that some unices may not have =
it.
AIX does not, as I recall, have a daemon() call. That's one OS where you
will have a learning experience.
There are also a number of
Thanks, Steven!
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
When was AC_PROG_CC_C89 introduced?
I like being able to use as old a version of autoconf as possible, and
it looks like I'm going to need to go from using AC_PROG_CC to
AC_PROG_CC_C89 now that I am no longer supporting KR C for one
project...
Speaking of which, how difficult would it be to list
I'd say the answer to the original question is it depends on whether or
not the package author looks at that field and does anything with the
information.
I'd suspect the odds are that for anything other than a compiler (and
possibly an assembler or linker) the package author just won't worry
I understand and agree with the coding standards, and it would be nice
if, for example, each invoked configure noted which options it did
anything with, and if the parent configure process noted usage it
should not be all that hard to have the top-level configure process
write a note saying that a
Not using AC_C_CONST might not be an option for folks who need to deal
with older C compilers, but I can see that the number of folks who need
both older C compilers *and* C++ is probably a *very* small number.
H
___
Autoconf mailing list
Hi Jian,
I believe the problem is the double quoting.
Please try:
AS_HELP_STRING([--with-bar=DIR], [Where to find bar libs])
instead.
H
--
I tried to use AS_HELP_STRING and found that we cannot double quote its
parameters. For example, I wrote a testing configure.ac like this:
A reasonable solution would be standard tests as described above:
whether the argument to `return' in `main' is ignored, and, if yes,
how to call `exit' properly.
Yes, something like that would be reasonable, if someone could take
the time to write it, and (more important) test it on the
[AC_ARG_WITH([foo],
AS_HELP_STRING([--with-foo],
[use foo (default is NO)]),
[ac_cv_use_foo=$withval], [ac_cv_use_foo=no])
AC_CACHE_CHECK([whether to use foo],
FreeBSD does all of its ports/ builds using a configure target of
${ARCH}-portbld-freebsd${OSREL} - perhaps you could do something similar
and see if you need to tweak config.guess/config.sub and supply some
basic scripts for what will look like a cross-compile so that your work
is mostly done.
H
This probably better asked on the automake@ list.
You can specify the build order in the SUBDIRS variable, and '.' can be
one of the things specified. By default, . is built first (as I
recall).
Just put . in the correct place in your SUBDIRS list.
H
Ralf,
You can specify the build order in the SUBDIRS variable, and '.' can be
one of the things specified. By default, . is built first (as I
recall).
It's the other way round: by default, the build order is depth-first,
i.e., '.' is built last. See `info Automake Subdirectories'.
I thought he was ssaying that if /bin/ls uses RPATH then configure
should use RPATH, too.
H
--
Patrick Welche [EMAIL PROTECTED] writes:
On Thu, Jul 20, 2006 at 07:03:27PM -0700, Russ Allbery wrote:
Adding -R for system X libraries is always the wrong thing to do on
Debian systems and
I thought he was ssaying that if /bin/ls uses RPATH then configure
should use RPATH, too.
H
--
Patrick Welche [EMAIL PROTECTED] writes:
On Thu, Jul 20, 2006 at 07:03:27PM -0700, Russ Allbery wrote:
Adding -R for system X libraries is always the wrong thing to do on
Debian systems and
./configure CFLAGS=-I/sw/include LDFLAGS=-L/sw/lib -lintl CXXFLAGS=-I/
sw/include
Do you really need to set CPPFLAGS=$CFLAGS? I think that is not needed.
If it's a -I, it should be in CPPFLAGS and not CFLAGS.
And there are still some cases where sometimes both are needed, IME.
H
On the machines where this apparently works, AC_PROG_LIBTOOL is in
aclocal.m4, but on subdirs where it does not work, AC_PROG_LIBTOOL is
*not* in aclocal.m4
How do you invoke the subdir configure scripts from inside of your
toplevel configure script?
The bootstrap script runs 'autoreconf
Hi,
first, run aclocal, it should install the AC_PROG_LIBTOOL macro to
aclocal.m4.
Then run autoconf.
autoreconf does this.
The fragment I posted works on many machines and does not work on some
machines.
In particular, I have a nested repo, where topdir/configure.ac uses
Clarification:
first, run aclocal, it should install the AC_PROG_LIBTOOL macro to
aclocal.m4.
Then run autoconf.
autoreconf does this.
autoreconf runs aclocal is what I meant.
On the machines where this apparently works, AC_PROG_LIBTOOL is in
aclocal.m4, but on subdirs where it
With a bit of digging I can see that the configure.ac file that
(on a machine that demonstrates this problem) autom4te sees:
% cd autom4te.cache/
% grep AC_PROG_LIBT *
output.0:AC_PROG_LIBTOOL
output.1:AC_PROG_LIBTOOL
output.3:AC_PROG_LIBTOOL
requests:'AC_PROG_LIBTOOL' =
Here's a small configure.ac that demonstrates the problem:
AC_INIT(foo, 1.0, [EMAIL PROTECTED])
AC_PROG_LIBTOOL
AC_OUTPUT
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
What version of automake is installed there? automake --version
should tell you.
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
autoconf 2.59 and libtool 1.5.6.
I'm seeing this on a bunch of different systems (the following is from
FreeBSD, but I'm also seeing it on Solaris9 and 10, and some others):
...
autoreconf259: configure.ac: not using Libtool
configure.ac:10: error: possibly undefined macro: AC_PROG_LIBTOOL
Hi Ralf,
autoconf 2.59 and libtool 1.5.6.
I'm seeing this on a bunch of different systems
autoreconf259: configure.ac: not using Libtool
configure.ac:10: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
The bug reporter provided a sample configure.in that triggered
the problem. If you have access to a SunOS 4 system, then
perhaps you could try out it out with current CVS autoconf to see
if it is still a problem. I suspect that it is, though.
I'm on a small vacation until next Thursday - I
I see that there is some mention of SunOS 4 in the Autoconf
documentation, but I'm not sure that it's really supported
anymore. Is it worth my keeping this bug around anymore, or
should I close it as SunOS 4 no longer supported?
I'm pretty sure we still have bunch of SunOS 4 users in the
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
.../configure CFLAGS=-g
This sucks too - it means one has to do separate configure runs for
debug, production, profiled, etc. builds
It would be
1 - 100 of 235 matches
Mail list logo
