Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Hi, here's a trivial patch for compiling dev-lang/lua with g++ instead of gcc.

It solves some trouble with some package, e.g. games-fps/edge (see bug
#188214).

Created an attachment (id=162816) [details]
patch for dev-lang/lua-5.1.3-r4

This patch is backwords. But it should not be required. Can you explain a bit
more  why it should be built with $CHOST-g++  vs $CHOST-gcc ? Perhaps if that
is introduced so should the nocxx USE flag to keep the existing behavior.

(In reply to comment #2)
> This patch is backwords. But it should not be required. Can you explain a bit
> more  why it should be built with $CHOST-g++  vs $CHOST-gcc ? Perhaps if that
> is introduced so should the nocxx USE flag to keep the existing behavior.
> 

I straight report the upstream's explanation:

"Lua MUST be compiled with g++ and not gcc. That's because it needs to use
special C++ exception stuff for handling errors properly.

That explains your missing symbols, the linker is looking for C++ mangled
symbol names instead of normal C symbol names (or vice versa)."

See also here: http://edge.sourceforge.net/phpBB2/viewtopic.php?p=2722#2722

I'd like to introduce a cxx flag to address this situation. Compiling with gcc
is the lua upstream default and it should be kept that way.

Are there any objections?

(In reply to comment #4)
> I'd like to introduce a cxx flag to address this situation. Compiling with gcc
> is the lua upstream default and it should be kept that way.
> 
> Are there any objections?
> 

No, it's a good solution for me.

So the edge ebuild just will need a classic "built_with_use || die" trick or,
in the future, the great USE dependencies feature (EAPI-2).

i just committed the ebuild (5.1.4-r1).

EAPI-2 is already live, so you can just say DEPEND="dev-lang/lua[cxx]" :)

This seems rather strange.
Shouldn't this rather be solved by adding
extern "C" {...}
around lua includes in src/i_luainc.h ?
(OK, I'm not sure if this would be a correct solution, 
but this seem more sane).

Consider above sort of confirmed.
I've just tried it and edge did run afterwards.

This seems weird to me.  Now if Lua is built with g++, my programs that link
against it also have to be built with g++, or they don't link correctly. 
Adding USE="-cxx" for Lua fixed that issue, but I don't have a very hard time
imagining that sooner or later we will have one package in the tree that needs
lua built with g++ and another that needs it built with gcc, which would
prevent them from being installed at the same time.  I agree with Rafał that
this should be addressed with some more portable fix.

I'd say first bugs caused by this solution have hit bugzilla
(bug 242174 and bug 242170).

I think this fix should be reconsidered as it breaks packages. Lua is C
application and should be compiled with C compiler only! Please, explain in
little more details what exceptions C code of lua starts to use when it is
compiled with g++?

Missing symbols are quite understandable as g++ mangle symbols. Read about that
here:

http://en.wikipedia.org/wiki/Name_mangling#Handling_of_C_symbols_when_linking_from_C.2B.2B

Currently I consider what was added to the tree as very nasty hack. Please
revert.

I haven't tested but take a look at  Rafał's suggestion (comment #7). It looks
much more sane (and again read above link).

I think main problem here lies in the lua upstream (as I wrote in
bug 242170#c4).
Lua was designed to be too embeddable - upstream was so focused on static
linking,
that it hasn't considered the effect of some of its design choices
for shared libs.
Of course, I don't feel as an expert on this topic,
but I'd like to hear an opinion or two from such here.

Since there are ways to use lua in C++ code (see my comment in edge bug) I
think current problem lays in edge upstream. They should provide correct
solution...

Having system lua being built with C++ should be removed is it's not supported
by anybody.

And speaking about extern "C". lua provides lua.hpp for this exact case, but
although this'll possibly fix compilation this'll break error handling. And
error handling should be fixed by upstream...


Matti, could you revert that commit?

I've done so, and pulled the lua-5.1.4-r1 ebuild from the tree.
sorry for the confusion it caused.

Well, compiling lua with "extern C" causes some disadvantages to exception
handling it seems. While this may be a reason to compile lua with C++, as i've
written in the changelog entry, the benefits of doing this systemwide are much
lower than the disadvantages (other packages breaking, etc.)

Thus i think the burden really is on edge upstream. As i've seen on the other
bug, upstream is cooperative and a solution in the pipeline. Good news!

Should be finally resolved, then. As the "solution" is the status quo, bug is
marked wontfix.