| Summary: | app-emulation/xen-tools-4.3.0 does not respect CC, AR, RANLIB | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Julian Ospald <hasufell> |
| Component: | New packages | Assignee: | Gentoo Xen Devs <xen> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | QA | CC: | idella4 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 243502 | ||
| Attachments: | xen-tools-4.3.0:20130722-000248.log | ||
22 Jul 2013; Ian Delaney <idella4@gentoo.org> files/xen-4-fix_dotconfig-gcc.patch, files/xen-4.2.0-anti-download.patch, xen-tools-4.3.0.ebuild: Add vars AR, RANLIB to build, addresses Bug #477676 Try it then. still have it in two places: ar cr gx_all.a gx_comm.o gx_main.o gx_utils.o gx_local.o # problem with ld using -m32 [...] ar cr xg_all.a xg_main.o # problems using -m32 in ld and CC is not respected in even more the CC instances I believer are a bridge too far waay too far The ar I'll look at. "a bridge too far away"? it's a metaphor. diff -ur xen-4.3.0.orig/tools/debugger/gdbsx/xg/Makefile xen-4.3.0/tools/debugger/gdbsx/xg/Makefile --- tools/debugger/gdbsx/xg/Makefile 2013-07-09 18:46:56.000000000 +0800 +++ tools/debugger/gdbsx/xg/Makefile 2013-07-23 16:14:18.442750361 +0800 @@ -5,7 +5,7 @@ XG_OBJS := xg_main.o CFLAGS += $(CFLAGS_xeninclude) - +AR="ar" .PHONY: all all: build @@ -16,7 +16,7 @@ # build: mk-symlinks xg_all.a xg_all.a: $(XG_OBJS) Makefile $(XG_HDRS) - ar cr $@ $(XG_OBJS) # problems using -m32 in ld + $(AR} cr $@ $(XG_OBJS) # problems using -m32 in ld # $(LD) -b elf32-i386 $(LDFLAGS) -r -o $@ $^ # $(CC) -m32 -c -o $@ $^ I don't know why this doesn't work but it doesn't. It's basically the same formula applied to tools/debugger/gdbsx/gx/Makefile in the new patch which works fine. Feel free to have a try, mine didn't work. It's 1 single instance. Re cc, I believe this sample is what you're referring to. make[2]: Entering directory `/mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.3.0/work/xen-4.3.0/tools/qemu-xen-traditional-dir' CC qemu-nbd.o CC qemu-tool.o CC osdep.o CC cutils.o CC qemu-malloc.o for the compiling of the low level drivers that make xen xen. This has been in place from xen ebuild inception. They build fine and threaten nought. Do we really have to go there, or are 'we' being downright priggish? 23 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/xen-tools-4.3-ar.patch, xen-tools-4.3.0.ebuild: patch to correct AR use wrt Bug #477676 (In reply to Ian Delaney from comment #5) > > Re cc, I believe this sample is what you're referring to. > > make[2]: Entering directory > `/mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.3.0/work/xen-4.3.0/tools/ > qemu-xen-traditional-dir' > CC qemu-nbd.o > CC qemu-tool.o > CC osdep.o > CC cutils.o > CC qemu-malloc.o > > for the compiling of the low level drivers that make xen xen. > This has been in place from xen ebuild inception. They build fine and > threaten nought. Do we really have to go there, or are 'we' being downright > priggish? > > 23 Jul 2013; Ian Delaney <idella4@gentoo.org> > +files/xen-tools-4.3-ar.patch, > xen-tools-4.3.0.ebuild: > patch to correct AR use wrt Bug #477676 No, I am not. The above thing is actually just a "verbose build log" bug. There are direct calls to "gcc" in the build log, just grep for it. ok I'll re-look I do believe we're down to ar cr xg_all.a xg_main.o # problems using -m32 in ld Your turn, otherwise let it lie. 23 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/xen-tools-4.3-ar-cc.patch, -files/xen-tools-4.3-ar.patch, xen-tools-4.3.0.ebuild: renamed patch to capture ar & cc, extended the patch to honour tc-getCC, almost fixes Bug #477676 |
Created attachment 353800 [details, diff] xen-tools-4.3.0:20130722-000248.log in several places, not everywhere