revealed after fixing bug 449516 gcc -O2 -fomit-frame-pointer -Wall -march=core2 -O2 -pipe -Wall -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U_FORTIFY_SOURCE -fno-stack-protector -DLUA_XROOT=\"/usr/\" -c -o lib_base.o lib_base.c
other versions probably affected as well unless they switched to a different build system
AR is affected as well ar rcus libluajit.a lj_vm.o lj_gc.o lj_err.o lj_char.o lj_bc.o lj_obj.o lj_str.o lj_tab.o lj_func.o lj_udata.o lj_meta.o lj_state.o lj_dispatch.o lj_vmevent.o lj_api.o lj_lex.o lj_parse.o lj_ir.o lj_opt_mem.o lj_opt_fold.o lj_opt_narrow.o lj_opt_dce.o lj_opt_loop.o lj_opt_split.o lj_mcode.o lj_snap.o lj_record.o lj_crecord.o lj_ffrecord.o lj_asm.o lj_trace.o lj_gdbjit.o lj_ctype.o lj_cdata.o lj_cconv.o lj_ccall.o lj_carith.o lj_clib.o lj_cparse.o lj_lib.o lj_alloc.o lib_aux.o lib_base.o lib_math.o lib_bit.o lib_string.o lib_table.o lib_io.o lib_os.o lib_package.o lib_debug.o lib_jit.o lib_ffi.o lib_init.o
solution: emake Q= CC="$(tc-getCC)" TARGET_AR="$(tc-getAR) rcus"
maintainer says cross compiling is broken and he does not care about alternative compilers
(In reply to comment #4) > maintainer says cross compiling is broken and he does not care about > alternative compilers This is a partial true. cross compilation of luajit is really broken and unsuported by the maintainer (myself). If someone wants to provide patches with *proper* support for cross-compiling *and* want to maintain the cross compiling builds (e.g. test all the supported arches for every release) I can accept it, but I'm not going to do this work myself. luajit isnt even keyworded for all the arches supported upstream due to lack of manpower/hardware to test it properly. And about me not caring about alternative compilers, it is a lie. I'm a big fan of clang, for example, but upstream just supports gcc.
(In reply to comment #5) > And about me not caring about alternative compilers, it is a lie. I'm a big > fan of clang, for example, but upstream just supports gcc. If we would follow that philosophy we would be stuck without the ability to test and improve things. Clang is in no way supported as system-wide compiler yet (see the tracker) and everyone who tests ebuilds with it knows that. But we are unable to test your ebuild with clang, because of an unrelated argument. If it is known to break the project at runtime, then you can do a toolchain-check in pkg_setup/pkg_pretend. If it is known to break build-time, then just leave it that way. It's expected and I want it to fail, so I am aware that my system-wide set compiler does not work instead of some hidden stuff that will just use gcc instead. I wonder how many packages we would have to remove if we only support the stuff upstream supports too. That argument alone is rather silly. Most upstreams don't support unbundling libraries, but we do it, most upstreams don't support patching their build system because it ignores all kinds of things, but we do it, most upstreams don't support version xy of a library, but we do it. Because of that I still think that you don't care, because the fix is extremely trivial, yet you refuse to apply it. But anyway, I don't care anymore either. I will be preferring bundled versions of luajit instead.
Despite these differences I apologize if my opinion came too strong or if you feel insulted. That was not intended.
Ok, I'll say this for the last time... I WON'T support (or even make it easier to use) anything unsupported upstream for luajit. And cross-compilling support WON'T be added until done properly.
(In reply to comment #7) > Despite these differences I apologize if my opinion came too strong or if > you feel insulted. > > That was not intended. I don' care about your insults, but please stop trying to mess with things yo clearly don't know. lua/luajit are "special" cases and everybody involved on its packaging knows it. Please don't try to push the shiny rules you learned last week here. :(
You did not explain why that case is special so don't expect others to understand things you cannot explain yourself.
(In reply to comment #10) > You did not explain why that case is special so don't expect others to > understand things you cannot explain yourself. I'm not going to waste my time with this. you can find these reasons yourself looking at the lua mailing list or even the bugs reported here for the recent lua breakage. I'm saying that I won't do anything unsupported upstream for a reason. Please stop complaining.I wont reply to this bug anymore.
