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 lib_a-tmpfile64.o
ok, added them in all emakes in src_compile. I take it inly required in src_compile Ago?
Ago; 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
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)
eeer good, but do you know what does?
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 @@ SHAREDLIBV=libz.so.1.2.3 SHAREDLIBM=libz.so.1 -AR=ar rc +AR=ar RANLIB=ranlib TAR=tar SHELL=/bin/sh @@ -68,7 +68,7 @@ fi libz.a: $(OBJS) $(OBJA) - $(AR) $@ $(OBJS) $(OBJA) + $(AR) rc $@ $(OBJS) $(OBJA) -@ ($(RANLIB) $@ || true) >/dev/null 2>&1
never mind, thanks anyway
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 <idella4@gentoo.org> 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, Ago; 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 fi 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.
