Hi, Renato!
> ./configure: line 5110: syntax error near unexpected token `else'
> ./configure: line 5110: `else'
>
> and others...
>
> Pekka from silc runs autoconf 2.13 and he has no problems at all... is
> there some "backward incompatibility" in 2.5 with 2.13?
Most likely it's be just a resul
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Automake has been using libtool --mode=clean for some time, so
Gary> it makes sense to be consistent and allow each tool to provide a
Gary> cleanup switch of sorts wherever it makes sense...
!!!
Great!
| Hi, i got a CVS tree from SILC.org and tryied to configure but i had some
| "syntax error"s just like invalidating the syntax below:
|
| if (foo == bar); then
I suppose you meant to write square brackets here, and a single equal sign.
|
| else
| ...
|
| saying:
|
| ./configure: line 5110
Hi, i got a CVS tree from SILC.org and tryied to configure but i had some
"syntax error"s just like invalidating the syntax below:
if (foo == bar); then
else
...
saying:
./configure: line 5110: syntax error near unexpected token `else'
./configure: line 5110: `else'
and others...
Pekka fro
Hi Vasek,
On Thu, Aug 09, 2001 at 07:02:57PM +0100, Vaclav Barta wrote:
> I really don't like conflating the C and C++ compilers - I guess
> practically every C++ compiler is also a C compiler, but it may
> very well require explicit switches to force the language (i.e.
> Visual C++ compiles *.C
Ossama Othman wrote:
> On Wed, Aug 08, 2001 at 08:48:07PM +0100, Vaclav Barta wrote:
> > Stephen Torri wrote:
> > > CC="$CXX"
> > > AC_PROG_LIBTOOL
> > > AC_LIBTOOL_CXX
> > > LIBTOOL="$LIBTOOL --tag=CXX"
> > >
> > > Are these calls still necessary to make libtool work with > > Well, they sure
>se
On Thursday 09 August 2001 11:46 am, Akim Demaille wrote:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> Am 09 Aug 2001 11:40:06 +0200 schrieb Akim Demaille:
> >> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> Though I agree that it would be desirable
> | > In fact, I realized that latter on, and changed that, but I suppose
> | > the mere presence of Autoconf (now renamed Autom4te) on the CVS repo
> |
> | Actually, no you didn't - the problem is that it still has files in it
> | (otherwise cvs update -dP would have pruned it).
>
> :-)=)
>
> Ahe
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> Am 09 Aug 2001 11:40:06 +0200 schrieb Akim Demaille:
>> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
Ralf> Though I agree that it would be desirable to let autoconf do
Ralf> this cleanup, I fail to see how autoconf
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
[...]
Akim> Sure. But the hypothesis is `the first files have been more tested
Akim> and are less likely to be guilty'.
Akim> For instance, it makes no sense to look for an unexpanded AC_TRY_RUN
Akim> in autoconf.m4, or an AT_CHECK in
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
"Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
adl> [...]
Akim> * Output the actual line where the culprit was found, i.e., not
Akim> the _input_ file, but the _output_ file.
adl> This would be more helpful, methinks.
Ag
Am 09 Aug 2001 11:40:06 +0200 schrieb Akim Demaille:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> Though I agree that it would be desirable to let autoconf do
> Ralf> this cleanup, I fail to see how autoconf could do this job.
>
> I thought several times about the fact
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
[...]
Akim> * Output the actual line where the culprit was found, i.e., not
Akim> the _input_ file, but the _output_ file.
This would be more helpful, methinks.
Akim> * Look for the culprit token in all the sources in reversed order
A
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> Though I agree that it would be desirable to let autoconf do
Ralf> this cleanup, I fail to see how autoconf could do this job.
I thought several times about the fact that some clean up targets
should not be handled by the Makefile
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> Instead, you could grep the generated configure for occurences of
adl> dnl and AC_LIBTOOL_CXX, it should be easier to spot the error.
There are several issues here I'd like to comment.
First of all, this scheme (looking in the
| As a workaround (so Python users don't require a CVS or hacked version of
| autoconf), you could strip '-g' from CFLAGS on BeOS (as it seems to be that
| flag that produces the .xSYM file) in configure.in.
|
| Index: lib/autoconf/lang.m4
| ==
| > In fact, I realized that latter on, and changed that, but I suppose
| > the mere presence of Autoconf (now renamed Autom4te) on the CVS repo
|
| Actually, no you didn't - the problem is that it still has files in it
| (otherwise cvs update -dP would have pruned it).
|
| $ cd lib
| $ cvs upd
| I don't know if it is really a bug or if I misuse autoconf in any
| way. Any help will be welcome and thanks for replying (if any) by
| using my email (as I said I'am not subscribed to any list).
Due to insecure code in Automake. Here is what the Autoconf doc says:
New Macros
--
18 matches
Mail list logo
