Short answer thus far is I don't understand what I have changed. To the best of my understanding I am running default ~amd64 system. I have tried unemerging busybox and I was then able to compile my kernel but busybox is pulled by portage on my next -uDNv @system.

FYI equery u busybox shows this

Found these USE flags for sys-apps/busybox-1.20.0:
U I
+ + ipv6 : Adds support for IP version 6
- - make-symlinks : Create all the appropriate symlinks in /bin and /sbin.
- - math : Enable math support in gawk (requires libm)
- - mdev : Create the appropriate symlink in /sbin and install mdev.conf and support files
+ - pam : Adds support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
- - savedconfig : Use this to restore your config from /etc/portage/savedconfig ${CATEGORY}/${PN}. Make sure your USE flags allow for
appropriate dependencies
- - sep-usr : Support a separate /usr without needing an initramfs by booting with init=/bbinit
- - static : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

also it appears to be effected man pages and dispatch-conf are not working properly

"ar" is the library archiver. I'm surprised busybox actually has an 'ar' module, normally 'ar' is handled by binutils.

Do you have a /usr/bin/ar ? If so, try removing the symlink in /bin and seeing if it works again.

This is a "full" not a reduced setup machine? I have a machine that I use busybox for most binaries in /bin, but it's not really good for development/compiling. In fact it doesn't even have portage installed..._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

"ar" is the library archiver. I'm surprised busybox actually has an 'ar' module, normally 'ar' is handled by binutils.

Do you have a /usr/bin/ar ? If so, try removing the symlink in /bin and seeing if it works again.

This is a "full" not a reduced setup machine? I have a machine that I use busybox for most binaries in /bin, but it's not really good for development/compiling. In fact it doesn't even have portage installed...

For some reason your machine decided to install all the symlinks for busybox as if USE=make-symlinks which is not the case...

When you unmerged busybox, did that symbolic link still linger?

Might want to check if there are any more symlinks to busybox in /bin - there shouldn't be any on a "full" system..._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

Hmm. I recall it doing that on my systems but it sure does not install to /bin. So are there a whole bunch of symlinks in /bin? That was printed during the install inside of the sandbox IIRC, so it's not the real install..._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

This looks like a USE flag artifact (making symlinks for all of the
programs that busybox could emulate if you wanted it to, as if
it were installed on an embedded or other system with very
tight disk space). Usually someone would only set such a USE
flag if they knew they needed it.

Mac Tzu, I realize this is a late response, but this problem occurred because you made /bin/sh symlink to busybox and Gentoo's busybox currently includes ar. busybox's shell will use any tools that busybox contains as shell builtins. Since its ar implementation does not support 's' (at least as busybox was compiled) and Linux's build system depends on it, the Linux build will break.

There is no sane reason that I can see for including ar in our busybox package, so I have filed bug #501092 for the Gentoo busybox maintainers requesting that they remove ar from our busybox package.

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 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...

I suggest that you test your suggestions before making them. Your suggestion will not work without kernel source modification that would cause Linus Torvalds to start uttering profanity. Not only should users never need to do that, but few would know how.

That being said, the fact is there is a bug and it will be corrected. There is no need to insult Gentoo developers by telling us that our distribution is good because it is bloated.

So it does work, you can coerce it to use the real ar with an alias. Whether it works for building a kernel - I have not tested, so if the kernel somehow uses this shell but avoids using its aliases, too bad. Maybe you shouldn't be trying to build kernels with busybox then.

ryao wrote:

There is no need to insult Gentoo developers by telling us that our distribution is good because it is bloated.

I do not remember insulting anyone, but if you do feel insulted personally, you're quite welcome to it.

Debian's busybox has about 100 builtins; Gentoo's has over 300. What you call bloated, I call useful. Removing builtins because they do not work in some scenarios - which is true for almost any builtin, since none of them are quite as fully featured as their counterparts - that's just a plain stupid idea. Whatever would you do that for? You'd fix one thing but break others.

Surprisingly enough, Debian's busybox, limited as it is, still includes ar - the non-posix-compliant one.

Like I mentioned in my earlier reply, I'd like to see a best of both worlds setting in busybox, that is: make it use the real binary if it's present, fall back to the builtin otherwise. Last time I checked, busybox did not have such a setting though; you had the choice between builtins overriding everything, or builtins being unavailable altogether unless you created symlinks or called them via 'busybox builtin ...' instead.

@ryao:

Also, are you testing your own suggestions? I just wanted to test the CONFIG_AR_POSIX you suggested in the bugtracker, but there does not seem to be such an option. Even reading the ar.c sourcecode directly, there simply isn't any code that would implement -s.

So it does work, you can coerce it to use the real ar with an alias. Whether it works for building a kernel - I have not tested, so if the kernel somehow uses this shell but avoids using its aliases, too bad. Maybe you shouldn't be trying to build kernels with busybox then.

Try doing kernel compilation. That won't work.

frostschutz wrote:

ryao wrote:

There is no need to insult Gentoo developers by telling us that our distribution is good because it is bloated.

I do not remember insulting anyone, but if you do feel insulted personally, you're quite welcome to it.

Debian's busybox has about 100 builtins; Gentoo's has over 300. What you call bloated, I call useful. Removing builtins because they do not work in some scenarios - which is true for almost any builtin, since none of them are quite as fully featured as their counterparts - that's just a plain stupid idea. Whatever would you do that for? You'd fix one thing but break others.

Surprisingly enough, Debian's busybox, limited as it is, still includes ar - the non-posix-compliant one.

Yet you cannot state a reason why this particular utility should be included.

frostschutz wrote:

Like I mentioned in my earlier reply, I'd like to see a best of both worlds setting in busybox, that is: make it use the real binary if it's present, fall back to the builtin otherwise. Last time I checked, busybox did not have such a setting though; you had the choice between builtins overriding everything, or builtins being unavailable altogether unless you created symlinks or called them via 'busybox builtin ...' instead.

@ryao:

Also, are you testing your own suggestions? I just wanted to test the CONFIG_AR_POSIX you suggested in the bugtracker, but there does not seem to be such an option. Even reading the ar.c sourcecode directly, there simply isn't any code that would implement -s.

That was actually the suggestion of one of the Gentoo developers responsible for maintaining busybox in Gentoo. I just passed it along.

Yet you cannot state a reason why this particular utility should be included.

It would break scripts that use it. It also would make it less capable as a rescue shell. Also it makes a bad example, sets a precedence for removing useful builtins just because they fail in some obscure use case.

You have not provided a reason why it should be removed, either. This thread here was about a case where someone inadvertently installed his system full of busybox symlinks. That broke the kernel compile, but also a whole bunch of other stuff:

Mac Tzu wrote:

it seems to set a whole lot of smylinks. which means is it effecting more than just ar. Maybe that is why is stopping manpages and dispatch-conf from working

The issue was also mentioned in other threads, also by users who did not have a valid reason to use busybox as their system shell. Those who do probably also (should) know how to work around such issues.

In this context the bug report is invalid to begin with. There is nothing to fix. The solution you are looking for is not removing utilities from busybox, but busybox from a system that needs a fully functional build environment rather than a minimal embedded/rescue environment, which is busybox' true purpose.

ryao wrote:

That was actually the suggestion of one of the Gentoo developers responsible for maintaining busybox in Gentoo. I just passed it along.

Yet you cannot state a reason why this particular utility should be included.

It would break scripts that use it. It also would make it less capable as a rescue shell. Also it makes a bad example, sets a precedence for removing useful builtins just because they fail in some obscure use case.

First, no one has justified this builtin as useful. Second, I am fairly confident zero scripts are using it.

frostschutz wrote:

You have not provided a reason why it should be removed, either. This thread here was about a case where someone inadvertently installed his system full of busybox symlinks. That broke the kernel compile, but also a whole bunch of other stuff:

His system had 1 busybox symlink. It is /bin/sh and eselect-sh permitted this until very recently. As for why it should be removed, the concept that it never should have been there in the first place is a fairly good one.

For ordinary Gentoo users with average knowledge, like me,
the current most serious problem is
not an ideological legitimacy on the system,
but the fact that you will never succeed to compile kernel now.

I would like you, the intelligent relevants, to propose some practical solutions on this problem._________________Hiroshi Takenaka, Kyoto, 617-0833 Japan

If you want to use busybox as /bin/sh set USE=savedconfig and configure the build in /etc/portage/savedconfig/sys-apps/busybox (I think you can use one per-package, but per-version is probably best.) If your machine is not embedded, and has the GNU userland available you should disable certain apps. I haven't gone down this route yet, as it's hassle, and Gentoo devs don't seem very interested in making things work out of the box, so you're pretty much on your own. It was easier just to go back to /bin/sh linked to bash.

WRT building the kernel, every makefile that's any good should accept eg: make AR=/usr/bin/ar [target such as: install]. Just be sure to put the assignments before any target name.

Two other possible options ... one is to install app-shells/ash-bb::foo-overlay which is a (standalone) ash so no extranious busybox utilities (it can also be built statically, with USE="static", if needed). The other is to use app-shells/dash as the posix shell ...