-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 12/14/2007 7:03 AM:
>> What is the m4_provide_if? I didn't find it in the manual of autoconf
>> and m4.
>
> It's in m4sugar.
>
>> Anyways, does this guarantee me that the user did INVOKE the give
>> macros, not merely t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Adding bug-autoconf, replies can drop libtool]
According to Paolo Bonzini on 12/14/2007 5:24 AM:
>
> You can use m4_provide_if like this:
>
> m4_define([m4_provided], [
> m4_provide_if([AC_PROG_LIBTOOL], [], [
> m4_p
m4_define([m4_provided], [
m4_provide_if([AC_PROG_LIBTOOL], [], [
m4_provide_if([LT_INIT], [],
[m4_warn([syntax], [Libtool required by $1])])])])])
...
m4_provided([MY_MACRO_NAME])
I didn't count the number of closing brackets.
What is the m4_provide_if? I didn't
Hello Craig,
* Craig Sanders wrote on Fri, Jun 15, 2007 at 10:06:57AM CEST:
>
> I have just installed automake 1.10 and autoconf 2.61 on my system. I
> am developing a package which uses GNU Autotools and the configure.ac
> file for my package contains the following line ;
>
&g
Hello all.
I have just installed automake 1.10 and autoconf 2.61 on my system. I am
developing a package which uses GNU Autotools and the configure.ac file for my
package contains the following line ;
AC_PROG_LIBTOOL
When I run autoconf it complains, giving me the following message
> > 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?
T
On Mon, 2006-06-26 at 19:39 +, Harlan Stenn wrote:
> Clarification:
>
> > > first, run aclocal, it should install the AC_PROG_LIBTOOL macro to
> > > aclocal.m4.
> > > Then run autoconf.
> >
> > autoreconf does this.
>
> autoreconf runs
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
ac
> 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 to
Hi,
first, run aclocal, it should install the AC_PROG_LIBTOOL macro to
aclocal.m4.
Then run autoconf.
The info from your preceding mail does not pbring anything new:
% cd autom4te.cache/
% grep AC_PROG_LIBT *
output.0:AC_PROG_LIBTOOL
output.1:AC_PROG_LIBTOOL
output.2:AC_PROG_LIBTOOL
output.3
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
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_LI
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
Hi Harlan,
* Harlan Stenn wrote on Mon, Jun 12, 2006 at 08:41:34PM CEST:
>
> 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_
On Fri, 15 Oct 2004, Adam Dyga wrote:
That's strange because other C++ libraries (I've tested some - libds for
example) use AC_PROG_LIBTOOL macro call too and configure doesn't make those
strange checks later.
Some packages include a libtool which has been patched to only test
th
On Friday 15 October 2004 14:00, Bob Friesenhahn wrote:
> On Fri, 15 Oct 2004, Adam Dyga wrote:
> > I create shared library, so I had to put AC_PROG_LIBTOOL macro call in
> > configure.in.
> > The result is that configure script makes some strange and unnecessary
> > (
On Fri, 15 Oct 2004, Adam Dyga wrote:
I create shared library, so I had to put AC_PROG_LIBTOOL macro call in
configure.in.
The result is that configure script makes some strange and unnecessary (at
least for me ;) ) checks now, e.g:
checking for g77... no
checking for f77... no
checking for xlf
Hi ,
I create shared library, so I had to put AC_PROG_LIBTOOL macro call in
configure.in.
The result is that configure script makes some strange and unnecessary (at
least for me ;) ) checks now, e.g:
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
Ludovic CourtÃs <[EMAIL PROTECTED]> writes:
> This seems to be a bug in GNU M4 1.4.1 (see [1, 2, 3] for details).
That bug should be fixed in GNU m4 1.4.2, available here:
ftp://ftp.gnu.org/gnu/m4/m4-1.4.2.tar.gz
(I write "should be" because I couldn't reproduce the problem on my
Solaris 8 box
Hi,
4 days, 12 hours, 31 minutes, 6 seconds ago,
Warren Young wrote:
> Someone is trying to build a project I maintain on Solaris 2.8 with
> current versions of the autotools. When he runs autoconf, it says:
>
> configure.in:17: /usr/local/bin/m4: ERROR: Reading inserted file: No
> such file o
"Gary V.Vaughan" <[EMAIL PROTECTED]> writes:
> the code needs to be checked carefully for similiar instances, in 1.4.1
OK, I systematically did that by looking for all uses of errno in
the code, looking for cases where errno's value may be garbage.
I generated a proposed new release here:
ftp://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Paul!
On 19 Aug 2004, at 18:59, Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
GNU m4 1.4.1 has a bug on Solaris, you should downgrade to 1.4 until
I release a fix in 1.4.2.
Ouch. What's the bug?
http://lists.gnu.org/archive/html/b
"Liu, Yigong" <[EMAIL PROTECTED]> writes:
> Thank you so much for your timely response and great efforts to maintain
> these public domain packages!
You're welcome. However, these packages are not in the public domain.
They're all GPLed, which means redistributors cannot place additional
copying
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> GNU m4 1.4.1 has a bug on Solaris, you should downgrade to 1.4 until
> I release a fix in 1.4.2.
Ouch. What's the bug?
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/a
; Autoconf List; M4
Subject: Re: AC_PROG_LIBTOOL error
Hi Warren,
GNU m4 1.4.1 has a bug on Solaris, you should downgrade to 1.4 until
I release a fix in 1.4.2.
Cheers,
Gary.
Liu, Yigong wrote:
> I have installed GNU m4 1.4.1. Looks like the issue is related to my
> autoconf2.59.
August 18, 2004 5:19 PM
> To: Autoconf List
> Subject: Re: AC_PROG_LIBTOOL error
>
> Paul Eggert wrote:
>
>>What versions, exactly?
>
>
> Autoconf-2.59
> Automake-1.8b
> Libtool-1.5
>
>
>>m4 1.4.1
>
>
> I'm not certain that they have
Warren Young <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> What versions, exactly?
>
> Autoconf-2.59
> Automake-1.8b
I don't recommend 1.8b; they should be running a released version of
automake. Preferably 1.9.1; or 1.8.5 if they're more conservative.
However, this shouldn't matter here:
TECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Warren Young
Sent: Wednesday, August 18, 2004 5:19 PM
To: Autoconf List
Subject: Re: AC_PROG_LIBTOOL error
Paul Eggert wrote:
> What versions, exactly?
Autoconf-2.59
Automake-1.8b
Libtool-1.5
> m4 1.4.1
I'm not certain that they have GNU
Paul Eggert wrote:
What versions, exactly?
Autoconf-2.59
Automake-1.8b
Libtool-1.5
m4 1.4.1
I'm not certain that they have GNU m4 installed. They may be using the
system m4.
I unpacked that distribution and ran 'autoconf', and it didn't report
any error.
Thanks for trying this. I'm glad my pa
Warren Young <[EMAIL PROTECTED]> writes:
> Someone is trying to build a project I maintain on Solaris 2.8 with
> current versions of the autotools.
What versions, exactly? Here's what I'm using:
Solaris 8 (sparc) with all recommended patches.
m4 1.4.1
autoconf 2.59
automake 1.9.1
You should in
Someone is trying to build a project I maintain on Solaris 2.8 with
current versions of the autotools. When he runs autoconf, it says:
configure.in:17: /usr/local/bin/m4: ERROR: Reading inserted file: No
such file or directory
Line 17 has "AC_PROG_LIBTOOL" on it.
He's rein
On Mon, Jun 02, 2003 at 05:03:39PM +0200, David Svoboda wrote:
> I've been using Compaq C++ compiler under Tru64 UNIX (alpha). In libtool
> it is supposed, that this compiler doesn't supprot -fPIC flag, which
> generates position independent code.
>
> If I compile my project by hand (with using -
I've been using Compaq C++ compiler under Tru64 UNIX (alpha). In libtool
it is supposed, that this compiler doesn't supprot -fPIC flag, which
generates position independent code.
If I compile my project by hand (with using -fPIC flag), everythig is ok.
If I let the autoconf and libtool do it, the
I'm trying to use the LIBTOOL call in my configure.in but I keep getting
the following error message when I run autoconf.
configure.in:9: error: possibly undefined macro: AC_PROG_LIBTOOL
Then when if I go ahead and run ./configure I get this message:
./conf
>>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> If you invoke AC_LANG(C++) above AC_PROG_LIBTOOL, you will find
Lars> that $ac_ext is "c" after AC_PROG_LIBTOOL has been run, and
Lars> invoking AC_LANG(C++) again will not dispatc
If you invoke AC_LANG(C++) above AC_PROG_LIBTOOL, you will find
that $ac_ext is "c" after AC_PROG_LIBTOOL has been run, and
invoking AC_LANG(C++) again will not dispatch the necessary shell
code to fix this again since AC_LANG thinks everything is hunky
dory. You need to switch
36 matches
Mail list logo
