Build fails like this: x86_64-pc-linux-gnu-gcc -O2 -Wall -ggdb -O2 -pipe -march=core-avx-i -Wall -fno-strict-aliasing -DLUA_USE_POSIX -DLUA_USE_DLOPEN -c -o linit.o linit.c x86_64-pc-linux-gnu-ar liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o x86_64-pc-linux-gnu-ar: invalid option -- '.' Usage: x86_64-pc-linux-gnu-ar [emulation options] [-]{dmpqrstx} <snip> make[1]: *** [liblua.a] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-analyzer/nmap-6.25/work/nmap-6.25/liblua' make: *** [lua_build] Error 2 * ERROR: net-analyzer/nmap-6.25 failed (compile phase): I believe this is caused by the sed invocations added to the ebuild to fix bug 445524. This version built for me before, and one of the lines being removed from liblua/Makefile is "AR= ar rcu". It's now trying to run "x86_64-pc-linux-gnu-ar <files>" where it probably previously ran "ar rcu <files>". I think that Makefile needs patching to make the line "$(AR) $@ $(BASE_O)" expect $AR to be just ar, without flags.
+ 16 Jan 2013; Sergey Popov <pinkbyte@gentoo.org> nmap-6.01.ebuild, + nmap-6.25.ebuild: + Fix building with USE='lua' due to recent changes, wrt bug #452452. Thanks to + Marien Zwart Good catch, that was my fault - liblua subdirectory Makefile is only one, who pass options to AR variable in this variable itself
I have removed all the unneeded sed invocations now. They are much too complicated, and setting AR/RANLIB on the make command line neatly overrides anything in the Makefiles anyway.
(In reply to comment #1) > + 16 Jan 2013; Sergey Popov <pinkbyte@gentoo.org> nmap-6.01.ebuild, > + nmap-6.25.ebuild: > + Fix building with USE='lua' due to recent changes, wrt bug #452452. > Thanks to > + Marien Zwart > > Good catch, that was my fault - liblua subdirectory Makefile is only one, > who pass options to AR variable in this variable itself Which it shouldn't anyway, so I have written an upstreamable patch for that. Maybe you want to take care of submitting that.
