[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] BUG: tolua verirrt

From: Tacvek
Subject: Re: [Enigma-devel] BUG: tolua verirrt
Date: Fri, 1 Dec 2006 15:56:02 -0500

----- Original Message ----- From: "Tacvek" <address@hidden>
To: <address@hidden>
Sent: Wednesday, November 29, 2006 5:08 PM
Subject: Re: [Enigma-devel] BUG: tolua verirrt

----- Original Message ----- From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, November 29, 2006 3:53 PM
Subject: Re: [Enigma-devel] BUG: tolua verirrt


Tacvek wrote:
make[1]: Leaving directory `/rep/svn/public/enigma-game-trunk/lib-src'
Making all in tools
make[1]: Entering directory `/rep/svn/public/enigma-game-trunk/tools'
gcc -I../lib-src/lua -x c++ -DENABLE_ASSERT -g -DCXXLUA -g -O2 -o tolua tolua-tolua.o tolua-toluabind.o -L../lib-src/lua -
llua -lstdc++ -lxerces-c -lpng -ldl

Please report the error to the maintainers of the autoconf/automake

Ronald, are you sure about that? It looks to me like either automake or autoconf decided to use gcc as the linker. IIRC that is perfectly valid, as gcc is happy to pretend to be a linker, and simply pass the relevant arguments on to the linker. The problem is that it used both $CFLAGS and $LDFLAGS when calling gcc as a linker. The "-x c++" causes gcc to ignore the file extentions, and attempt to compile the .o files as though they were C++ files, before trying to link them.

If there is a bug in atuoconf/automake I would say it is passing $CFLAGS to gcc when invoking gcc as a linker. That said, upsteam may feel that is the correct thing to do. I doubt upstream autoconf and automake maintainers support use of "-x c++" in $CLAGS, for many reasons, not the least of which is that that option is not very portable.

The problem should be reported. Especially as there are no obvious alternatives to compile "tolua".

As you figured out the above solution with "-x c++" do you know any alternative? What about the approach of renaming the sources that you tried in the beginning?

While the sources could be renamed, the easiest meathod of doing so prevents tolua compilation as C. (Which is what we are doing if lua is compiled as C). It would be preferable to keep that ability around, even if it is not used. I'm looking into why automake/autoconf is using $CFLAGS when invoking gcc as a linker. If I understand why, it would be easier to determine if it is a really a bug, or if a change to tools/Makefile.am are actually needed, and if so what the change should be.

hmm... it worked fine with autoconf 2.61 (the current latest in Debian), with automake 1.9.6.

I have not yet tested automake1.10... Will try that soon.

Autoconf 2.61 with automake 1.10 does show the problem.
I've found the change between automake 1.9 and 1.10 that is responsible.

The change is definately intentional. Indeed, it was only due to a bug in older automakes that
my code worked at all. Automake deliberately passes CFLAGS to the linker.

I think I have found a new workaround that is not likely to break.
I've attached the patch. The patch also does a little bit a unrelated cleanup to make automake happier.

Attachment: patch.diff.bz2
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]