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

Bug 455194

Summary: app-emulation/xen-pvgrub does not respect AR
Product: Gentoo Linux Reporter: Agostino Sarubbo <ago>
Component: New packagesAssignee: Gentoo Xen Devs <xen>
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 243502    

Description Agostino Sarubbo gentoo-dev 2013-02-02 21:11:50 UTC
You receive this bug because this package does not respect my system's AR ( x86_64-pc-linux-gnu-ar - /usr/bin/x86_64-pc-linux-gnu-ar ) and calls directly ar - /usr/bin/ar
The possible solutions to fix this issue are:
1)Fix the buildsystem, if you can
2)inherit toolchain-funcs and use tc-export AR
3)inherit toolchain-funcs and use emake AR="$(tc-getAR)"

As example:

ar cru lib.a lib_a-dummy.o lib_a-fdopen64.o lib_a-fgetpos64.o lib_a-fopen64.o lib_a-freopen64.o lib_a-fseeko64.o lib_a-fsetpos64.o lib_a-ftello64.o lib_a-stdio64.o 
Comment 1 Ian Delaney (RETIRED) gentoo-dev 2013-02-03 09:13:23 UTC
ok, added them in all emakes in src_compile.  I take it inly required in src_compile Ago?
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2013-02-04 04:30:56 UTC
Point 1. The emake occurs in src_compile and src_install.  I'm working on they're only needed in src_compile. correct me otherwise.

There are 4 instances of emake in src_compile.  The addition of AR="$(tc-getAR)" 'works' in the first 2 and causes the build to pull up when added to the last 2.

test & confirm & close accordingly
Comment 3 Tomoatsu Shimada 2013-02-07 05:26:53 UTC
According to xen-4.2.1/stubdom/zlib-x86_32/Makefile, the original zlib's Makefile assumes AR as "ar rc".
Just overriding AR with i686-pc-linux-gnu-ar(or something) doesn't work.

(that overriding somehow doesn't happen in amd64 but in x86)
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2013-02-10 07:46:03 UTC
eeer good, but do you know what does?
Comment 5 Tomoatsu Shimada 2013-02-10 10:35:37 UTC
I couldn't find out permanent solution for this issue so I had to just remove AR="$(tc-getAR)" from emake line. 

Perhaps patching zlib's Makefile like below(untested) would work but I don't really know if it's a good idea or not.  (is it possible, moreover?)

--- Makefile.orig	2013-02-10 19:28:24.250000000 +0900
+++ Makefile	2013-02-10 19:29:08.030000000 +0900
@@ -33,7 +33,7 @@
-AR=ar rc
@@ -68,7 +68,7 @@
 libz.a: $(OBJS) $(OBJA)
-	$(AR) $@ $(OBJS) $(OBJA)
+	$(AR) rc $@ $(OBJS) $(OBJA)
 	-@ ($(RANLIB) $@ || true) >/dev/null 2>&1
Comment 6 Ian Delaney (RETIRED) gentoo-dev 2013-02-10 14:31:24 UTC
never mind, thanks anyway
Comment 7 Ian Delaney (RETIRED) gentoo-dev 2013-02-19 19:30:50 UTC
1)Fix the buildsystem, if you can

Tomoatsu Shimada.  You have pretty well hit the nail on the head.  Your suggestion has support from a dev familiar with us use of ar.  You just missed

 sed -e s':AR=${AR-"ar rc"}:AR=${AR-"ar"}:' -i "${WORKDIR}"/zlib-1.2.3/configure

which took me a while to figure why the ar kept immediately re-appearing. I have incorporated the above plus your patch as a sed statement in the ebuild, though it is 'patchable'.

  19 Feb 2013; Ian Delaney <> files/xen-4.2.0-externals.patch,
  xen-pvgrub-4.2.0-r1.ebuild, xen-pvgrub-4.2.1-r1.ebuild:
  4.2.0-externals.patch improved and absorbs -CC.patch, external zlib build
  improved with contribution by Tomoatsu Shimada wrt Bug #455194,

After extensive testing, the build is absent of direct call to ar except for the final stage in amd64 in

if use multilib; then
       multilib_toolchain_setup x86
       emake -j1 CC="$(tc-getCC)" AR="$(tc-getAR)" \
       XEN_TARGET_ARCH="x86_32" -C stubdom pv-grub

and it amounts to only a handful of lines.  multilib_toolchain_setup x86, which pushes the (my) boundaries of toolchain and multilib knowledge, clearly clobbers both AR="$(tc-getAR)" and LD="$(tc-getLD)" when used in this final emake call.  I've put the query at least twice and received nothing in reply.  Fix it if you can, but I'm confident its presence in this build is a triviality as QA issues go.