Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 449518

Summary: dev-lang/luajit-2.0.0_beta7 calls cc and ar directly
Product: Gentoo Linux Reporter: Julian Ospald <hasufell>
Component: New packagesAssignee: Rafael Martins (RETIRED) <rafaelmartins>
Status: RESOLVED OBSOLETE    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 243502    

Description Julian Ospald 2012-12-31 21:54:08 UTC
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
Comment 1 Julian Ospald 2012-12-31 21:55:02 UTC
other versions probably affected as well unless they switched to a different build system
Comment 2 Julian Ospald 2012-12-31 22:11:46 UTC
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
Comment 3 Julian Ospald 2012-12-31 22:50:14 UTC
solution:

	emake Q= CC="$(tc-getCC)" TARGET_AR="$(tc-getAR) rcus"
Comment 4 Julian Ospald 2013-01-01 00:06:54 UTC
maintainer says cross compiling is broken and he does not care about alternative compilers
Comment 5 Rafael Martins (RETIRED) gentoo-dev 2013-01-01 04:22:51 UTC
(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.
Comment 6 Julian Ospald 2013-01-01 15:32:21 UTC
(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.
Comment 7 Julian Ospald 2013-01-01 15:47:22 UTC
Despite these differences I apologize if my opinion came too strong or if you feel insulted.

That was not intended.
Comment 8 Rafael Martins (RETIRED) gentoo-dev 2013-01-01 15:52:35 UTC
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.
Comment 9 Rafael Martins (RETIRED) gentoo-dev 2013-01-01 16:03:24 UTC
(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. :(
Comment 10 Julian Ospald 2013-01-01 16:05:13 UTC
You did not explain why that case is special so don't expect others to understand things you cannot explain yourself.
Comment 11 Rafael Martins (RETIRED) gentoo-dev 2013-01-01 16:21:07 UTC
(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.