Created attachment 304311 [details] dev-lang:lua-5.2.0:20120305-124952.log * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/bin/lua * /usr/bin/luac * /usr/lib/liblua.so.5.2.0
Created attachment 304315 [details, diff] Set SYSLDFLAGS, clean up Looks like the configure script doesn't substitute CFLAGS, LDFLAGS or anything much in the Makefiles, so src_compile still carries that burden.
Comment on attachment 304315 [details, diff] Set SYSLDFLAGS, clean up Oh, it shouldn't remove the tc-export CC.
Created attachment 304317 [details, diff] take 2
Thanks for catching this. Is there a specific reason you removed -DLUA_USE_LINUX from CFLAGS?
(In reply to comment #4) > Thanks for catching this. Is there a specific reason you removed > -DLUA_USE_LINUX from CFLAGS? No. Well yes: I originally assumed econf would now take care of the special stuff, so I started rewriting the ebuild (hence "take 2"). So it's probably a good idea to check whether 1) it is now set properly without our hacking or 2) whether it is used at all. :)
I see how adding (even minimal) autotools support can give the impression I ported the whole build system. This is not the case. The goal was to add a minimal configure file that would give me a local libtool binary. The rest of the build is still controlled by upstream's Makefile or rather my patched version of it. Keeping autotools out of the picture as much as possible was me being both lazy and conservative about deviating from upstream. So yes, setting LUA_USE_LINUX is still necessary as nothing in libtool or CFLAGS knows about it. I was mainly asking because I suspected it didn't work on x86-fbsd, for which lua is keyworded. If there are problems with that, I can probably move that bit to dynamic detection in configure.in. But for now, I just fixed the LDFLAGS part.
