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 attachment 162816 [details, diff] 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.
