Builtins in busybox are also builtins in busybox's shell. Busybox's ar does not support s, which breaks Linux kernel compilation because the Linux kernel requires it. I see no reason why sys-apps/busybox should include ar, so lets remove it. Otherwise, we need to add the s option to it to permit Linux kernel builds to succeed.
More specifically, the default for AR should probably match the default for RANLIB, and since RANLIB is off by default...
uhh, what now ? so what if `busybox ar` works ? `ar` found via the $PATH is the standard binutils ar. the fact that ranlib is disabled does not mean ar should also be. ranlib is an optional post-processing optimization step to create an index in large archives. ar itself is a simple archive management utility.
The beauty of Gentoo's busybox is that it's not castrated like Debian's. Why is anyone trying to build Linux from within a busybox shell anyway? Also, you can just alias ar=/usr/bin/ar as a workaround. Not sure if busybox has a setting to try the binary before builtin... it certainly has a setting to disable the builtin in the first place, but that causes other issues / requires you to create a ton of symlinks...
(In reply to SpanKY from comment #2) > uhh, what now ? so what if `busybox ar` works ? `ar` found via the $PATH > is the standard binutils ar. > > the fact that ranlib is disabled does not mean ar should also be. ranlib is > an optional post-processing optimization step to create an index in large > archives. ar itself is a simple archive management utility. Invoking a shell builtin ignores $PATH and all busybox utilities are builtins for the busybox shell. The busybox shell interpreter is remarkably POSIX conformant and quite excellent for a couple of reasons. However, the non-POSIX conformant ar builtin breaks things like the Linux build system. The two main reasons why using busybox as /bin/sh is desireable are: 1. It performs better, which is noticeable on systems with weak CPUs. Users like this. 2. It enables early detection of POSIX conformance bugs, which helps Gentoo FreeBSD. That being said, I am inclined to think that we have no reason to have ar in busybox. Is there any reason why we need it? If we really do need it, we could just enable CONFIG_AR_POSIX and this problem will go away.
(In reply to Andreas Klauer from comment #3) > The beauty of Gentoo's busybox is that it's not castrated like Debian's. Why > is anyone trying to build Linux from within a busybox shell anyway? Also, > you can just alias ar=/usr/bin/ar as a workaround. Not sure if busybox has a > setting to try the binary before builtin... it certainly has a setting to > disable the builtin in the first place, but that causes other issues / > requires you to create a ton of symlinks... The association between busybox shell and the build failure is very hard to make. I have had to explain this multiple times to several very intelligent people for them to understand what was happening. Failing to correct it is like leaving bear traps on the ground in an unlit room where people are expected to walk. The idea that people should have to workaround problems 99.9% of them cannot understand is sadistic. Also, I don't know what your complaint is with Debian's busybox, but that has nothing to do with Gentoo.
(In reply to SpanKY from comment #2) > uhh, what now ? so what if `busybox ar` works ? `ar` found via the $PATH > is the standard binutils ar. > On my regular desktop system, I did the following: # rm sh # ln -sf busybox sh # sh # which ar /usr/bin/ar # ls -alh /usr/bin/ar lrwxrwxrwx 1 root root 22 Dec 23 03:22 /usr/bin/ar -> x86_64-pc-linux-gnu-ar # ar BusyBox v1.21.0 (2013-12-07 13:59:16 EST) multi-call binary. Usage: ar [-o] [-v] [-p] [-t] [-x] ARCHIVE FILES Extract or list FILES from an ar archive -o Preserve original dates -p Extract to stdout -t List -x Extract -v Verbose # echo $PATH /root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3:/usr/lib64/subversion/bin So it seems that even if binutils' ar is in $PATH, when your sh is busybox, invoking ar invokes the builtin.
(In reply to Richard Yao from comment #5) > I have had to explain this multiple times to several very intelligent > people for them to understand what was happening. I was one of them. Even easier steps to reproduce: blueness@yellow ~ $ busybox sh ~ $ ls -alh `which ar` lrwxrwxrwx 1 root root 22 Dec 23 03:22 /usr/bin/ar -> x86_64-pc-linux-gnu-ar ~ $ ar BusyBox v1.21.0 (2013-12-07 13:59:16 EST) multi-call binary. Usage: ar [-o] [-v] [-p] [-t] [-x] ARCHIVE FILES Extract or list FILES from an ar archive -o Preserve original dates -p Extract to stdout -t List -x Extract -v Verbose
(In reply to Richard Yao from comment #4) the default busybox shell is meant as a rescue shell, not as a build shell. there are a lot of builtins that can easily break a lot of packages/tests. i don't think the default config should be considered safe for that use. so i have no intention of cutting out utils from the rescue shell simply because it breaks this use case. it would make more sense to create another USE flag that'd produce a second busybox with reduced command set. so as this bug stands, the answer is "no".
(In reply to SpanKY from comment #8) > (In reply to Richard Yao from comment #4) > > the default busybox shell is meant as a rescue shell, not as a build shell. > there are a lot of builtins that can easily break a lot of packages/tests. > i don't think the default config should be considered safe for that use. so > i have no intention of cutting out utils from the rescue shell simply > because it breaks this use case. > > it would make more sense to create another USE flag that'd produce a second > busybox with reduced command set. > > so as this bug stands, the answer is "no". I don't think you understand what my request is here. It is not to remove ar from busybox, but to make it stop having a POSIX non-conformant ar builtin. That means either removing ar or adding POSIX support. Adding POSIX support is a single config option. Do you have any objection to that?
(In reply to Richard Yao from comment #9) perhaps you should refresh & re-read your own posts ? you specifically requested its removal. you're certainly free to send patches to upstream busybox to add additional flags like this to it.
(In reply to SpanKY from comment #10) > (In reply to Richard Yao from comment #9) > > perhaps you should refresh & re-read your own posts ? you specifically > requested its removal. I stated there are two options for handling this and recommended removal. > you're certainly free to send patches to upstream busybox to add additional > flags like this to it. The code is *already* there. You just need to flip it on with CONFIG_AR_POSIX.
By the way, how can I build the kernel? I have also been in trouble in this issue for a month.
*** Bug 505578 has been marked as a duplicate of this bug. ***
I suggest closing this bug as WONTFIX. I find ar an useful tool in busybox (I actually used it in the past to create deb files that could be extracted with busybox dpkg). There are easy workarounds for using and external ar tool if needed. alias ar=/usr/bin/ar works in ash. Also there is no CONFIG_AR_POSIX.
