Advice needed on reinstall Gentoo or not[SOLVED]

[EasterParade]

I´ve prepared myself for reinstalling Gentoo, backed up all home and
some etc files and grub.conf...
Something tells me it´s time to do this as glibc keeps failing with sandbox
error and I cannot for the life of me figure out where I´ve f***** up.
Disabling sandbox for glibc is a workaround, not a solution and glibc is the
heart of the system.
I cannot downgrade glibc as I don´t have a gcc version with wihich a previous glibc
was built properly.
Couple o weeks ago i posted this issue but hardly anyone read it let alone
offered an idea. I figure there is no idea as it´s a dead end issue.
Gerard suggested that system is deeply troubled. I smirked at that but
he might have been right.
So here it is again, two questions added:
1. ANY idea where the problem lies?
2. time to reinstall?

[few]

Well, just a wild guess, but since it mentions /proc maybe something is wrong there. Is it mounted properly? Maybe it's a kernel configuration problem. You could try some pre-made kernel configs (search the forum).

Other than that, check if you have set strange things in make.conf and files in /etc/portage like package.env or bashrc.

Where is that thread you posted this first?

[EasterParade]

Thanks for answering, few!

[EasterParade]

Does the error refer to this kernel option:

[DirtyHairy]

I second few: the reference to /proc/self suggests the possibility of a kernel configuration problem. Perhaps you should try with a genkernel or a fresh kernel configuration, starting from scratch and only deviating from the default where absolutely necessary. Also, you should reproduce the error without the "-j3" in MAKEOPTS and post it again; it is hard to see what actually happened in the log you posted as the output of several different processes is interleaved.

[few]

You've got an interesting make.conf there. I don't see something obviously wrong in there. Please post "emerge --info" and "find /etc/portage".

You should whenever you try something to fix your problem rebuild sandbox before testing the glibc build.

[EasterParade]

Did 3.2.6 from scratch, leaving everything on default where
possible. Have done the same kernel from scratch on another
machine with a QuadCore - no probs there. Glibc is the only
part of system or any other package in world that fails. So
either it actually is a option within the kernel that conflicts
or it is software.
May be I should try a kernel seed ?
emerge busybox && emerge sandbox && emerge glibc turned up
the same outcome. I tried that a couple of times last week.

[few]

Did you already to try to install glibc without sandbox? Maybe doing that once fixes the problem.

Another wild guess: Do you have something installed in /usr/local?

[EasterParade]

When compiled with sandbox disabled glibc conpiles just fine.
But isn´t that just a workaround? You shouldn´t be forced to
do that each time you´d like to compile glibc.

And yes, there is the above mentioned Brother drivers in
/usr/local/. Already thought about removing them but dun knoe
how yet as they are shipped as rpm and if I try to uninstall em
with rpm -e system says it´s not installed.

I am doing a fresh kernel configuration just now, from scratch.
See where that leads to...

[EasterParade]

It WAS the Brother drivers. Might not have been properly
installed although this really useful color-laser printer/copier/scanner/fax
did work nicely. Pity actually but glibc compiled fine without them
Brother drivers.
So no need to reinstall my system

Will now have to find a way to take back my brilliant network Bro
for my box preferably without wrecking my system

Thank you very much for helping @few and @DirtyHairy ( funny user name )

transsib

on a sidenote Dirty Hairy you are based in Freiburg/Breisgau, Germany
just as me

[DirtyHairy]

It seems to me that the dynamic linker tries to access /proc/self for writing and triggers the sandbox violation. The access looks strange to me --- it looks like it tries to _create_ /proc/self instead. I don't think that this has anything to do with you screwing up the system, I rather think that it is a sandbox bug or a bug somewhere in glibc triggered by your particular system configuration. One last stab: have you run etc-update (or dispatch-conf) after remerging sandbox? What do you have in your /etc/sandbox.d?

[EasterParade]

@DirtyHairy
I suspected as much all along which is why I also suspected the
Brother driver to be the scapegoat respectively some mistake
while installing the driver.
Unfortunately I dun remember exactly how I installed the driver
after I´ve bought the device sometime last year.

I installed those drivers on another box in the network as well at the same time
where it does not conflict or even throw glibc off track.
So it is logical to assume that I´ve f***** up.

I´ve had it in for the Brother driver for quite some time but hesitated as the
printer is a marvel and I love it. Didn´t want a loose its functionality; could have
solved the conflict much earlier.

Instead I fiddled around with sandbox, upgraded it cause I hoped it could be a
bug caused by it - now I figure I´ve got proof for its innocence

I did not run dispatch.conf though, only etc-update and of course a whole
shit-load of revdep-rebuild over and over again.

[DirtyHairy]

I must admit that I'm dumbfounded. It might helpful to get a trace of what happens when the sandbox violation is triggered. I guess the easiest way to do this would be to change to the working directory after the violation occured, manually start up a sandbox with SANDBOX_VERBOSE=yes and run "make"; I think this should give you a stack trace. You could also try to get a strace of the failing command. When you attempt any of this, add "-g -O0" to your CFLAGS to enable debugging symbols and switch off optimization in the build.

In any case, I can't imagine any way the printer driver could have anything to do with this issue.

[EasterParade]