Mailing List Archive

Mathias W. wrote:
> Hi,
> As I mentioned previously without getting an answer
> (http://archives.gentoo.org/gentoo-mips/msg_00589.xml) I'm still having
> problems with compiling the kernel:
>
> LD .tmp_vmlinux1
> lib/lib.a: could not read symbols: Archive has no index; run ranlib to
> add one
> make: *** [.tmp_vmlinux1] Error 1
>
> I've been always told to run binutils-config which I've done now a
> thousand times. I tried to switch compilers several times. I even
> emerged an old version of binutils (with USE="multislot") to switch to
> (and back) - nothing helped.
> Has anybody an idea what to try before I'm going to setup the system
> again from scratch?

I did hit the ldscripts error, which needed a fix in binutils-config. But this
ranlib-based one, I haven't hit in the last few times I've run catalyst to build
newer livecds. All I can say, is use crossdev to completely remove all traces
of cross-compilers, then follow behind it in /usr and remove any left overs that
might be remaining (usually in /usr/${CHOST}/*). Then, remove all your kernel
trees.

Remerge everything, using gcc-4.1.2 and binutils-2.17, and cross fingers. Make
sure you're running "make vmlinux" for 64bit targets (IP28, IP27, IP30) or
vmlinux.32 for quasi-64bit targets (IP22, IP32). Also make sure you have the
latest crossdev too.

I can only think that this is residual goop leftover, possibly form that
ldscripts bug. Since catalyst stages nuke everything on a rebuild, when the
ldscripts bug was fixed, I may've just skipped over this issue by the nuking.
Cause else, this would be a kernel build failure, and I should've ran into it by
now.

As a last afterthought, make sure mips64-unknown-linux-gnu-ranlib exists and can
be ran.


--Kumba

--
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
gentoo-mips@gentoo.org mailing list

Kumba schrieb:

> I did hit the ldscripts error, which needed a fix in binutils-config.
> But this ranlib-based one, I haven't hit in the last few times I've run
> catalyst to build newer livecds. All I can say, is use crossdev to
> completely remove all traces of cross-compilers, then follow behind it
> in /usr and remove any left overs that might be remaining (usually in
> /usr/${CHOST}/*). Then, remove all your kernel trees.

I did this and hopefully removed everything which looked like mips64.

> Remerge everything, using gcc-4.1.2 and binutils-2.17, and cross
> fingers. Make sure you're running "make vmlinux" for 64bit targets
> (IP28, IP27, IP30) or vmlinux.32 for quasi-64bit targets (IP22, IP32).
> Also make sure you have the latest crossdev too.

Now I emerged gcc-4.1.2 but then kgcc64-4.1.2 fails during compile:

rm -f include/limits.h
cp xlimits.h include/limits.h
cp /var/tmp/portage/sys-devel/kgcc64-4.1.2/work/gcc-4.1.2/gcc/unwind-generic.h include/unwind.h
chmod a+r include/limits.h
rm -f include/README
cp /var/tmp/portage/sys-devel/kgcc64-4.1.2/work/gcc-4.1.2/gcc/../fixincludes/README-fixinc include/README
chmod a+r include/README
echo timestamp > stmp-int-hdrs
make[2]: *** No rule to make target `/usr/bin/mips64-unknown-linux-gnu-as', needed by `stamp-as'. Stop.
make[2]: Leaving directory `/var/tmp/portage/sys-devel/kgcc64-4.1.2/work/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/kgcc64-4.1.2/work/build'
make: *** [all] Error 2

!!! ERROR: sys-devel/kgcc64-4.1.2 failed.
Call stack:
ebuild.sh, line 1615: Called dyn_compile
ebuild.sh, line 972: Called qa_call 'src_compile'
ebuild.sh, line 44: Called src_compile
ebuild.sh, line 1305: Called toolchain_src_compile
toolchain.eclass, line 26: Called gcc_src_compile
toolchain.eclass, line 1541: Called gcc_do_make
toolchain.eclass, line 1415: Called die

!!! emake failed with all
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/sys-devel/kgcc64-4.1.2/temp/build.log'.

----------------------------------------
Now I'm not sure if this may be in relation to the cleaning because I had kgcc64-4.1.1 before.
(I'm pretty sure that I did too much cleaning because kgcc64-4.1.1 shows the same error now)

I think I rebuild this machine from Scratch: is there a newer stage3 available than this: stage3-mips4-2006.0.tar.bz2 ?

--
Mathias Weigt



--
gentoo-mips@gentoo.org mailing list

Ouch! When I do ebuilds, I allways use the -b to make binary packages for
quick reinstall or duplication on another machine. Perhaps you would like
some of my packages related to base and compiler???

-Scott-

On Mon, 2 Jul 2007, Mathias W. wrote:

> Now I'm not sure if this may be in relation to the cleaning because I had
> kgcc64-4.1.1 before.
> (I'm pretty sure that I did too much cleaning because kgcc64-4.1.1 shows the
> same error now)
>
> I think I rebuild this machine from Scratch: is there a newer stage3
> available than this: stage3-mips4-2006.0.tar.bz2 ?
>
> --
> Mathias Weigt
>
>
>
> --
> gentoo-mips@gentoo.org mailing list
>
>
>
--
gentoo-mips@gentoo.org mailing list