| 1 |
"Harry Holt" <harryholt@×××××.com> posted |
| 2 |
7c8072a00610271620o15838e70of02ad445af47849d@××××××××××.com, excerpted |
| 3 |
below, on Fri, 27 Oct 2006 19:20:39 -0400: |
| 4 |
|
| 5 |
> Arrgh! It did it again! I have no idea how to fix this. GCC will not |
| 6 |
> compile. Well... I think it compiles, but then dies at the end. I tried |
| 7 |
> running through the install/postinst/qmerge steps in ebuild, but that |
| 8 |
> doesn't seem to work (everything is still broken). revdep-rebuild wants |
| 9 |
> to emerge GCC first - there are several things broken, including |
| 10 |
> libfbdirect. |
| 11 |
> |
| 12 |
> gzipping man page: std::wstring.3 |
| 13 |
> gzipping man page: _var_tmp_portage_gcc-4.1.1_work_gcc-4.1.1_.3 |
| 14 |
>>>> Completed installing gcc-4.1.1 into /var/tmp/portage/gcc-4.1.1/image/ |
| 15 |
|
| 16 |
OK, yes, it finishes the "fakeinstall" step here, which is after the |
| 17 |
compile step, so it's done with that. |
| 18 |
|
| 19 |
> |
| 20 |
> --------------------------- ACCESS VIOLATION SUMMARY |
| 21 |
> --------------------------- |
| 22 |
> LOG FILE = "/var/log/sandbox/sandbox-sys-devel_-_gcc-4.1.1-30225.log" |
| 23 |
> |
| 24 |
> unlink: /usr/lib64/crt1.o |
| 25 |
> open_wr: /usr/lib64/crt1.o |
| 26 |
> unlink: /usr/lib64/crt1.o |
| 27 |
> -------------------------------------------------------------------------------- |
| 28 |
|
| 29 |
Sandbox violation. Sandbox is a protection mechanism that is supposed to |
| 30 |
keep the ebuild from overwriting anything on the main system during the |
| 31 |
compile and install steps, which should be done to temporary locations, |
| 32 |
prior to the qmerge to the main system. |
| 33 |
|
| 34 |
$equery b crt1.o |
| 35 |
[ Searching for file(s) crt1.o in *... ] |
| 36 |
sys-libs/glibc-2.5 (/usr/lib32/crt1.o) |
| 37 |
sys-libs/glibc-2.5 (/usr/lib64/crt1.o) |
| 38 |
|
| 39 |
OK, so that file belongs to glibc, not gcc. Why is gcc trying to unlink |
| 40 |
it, then write to it, then unlink it again? That's strange. |
| 41 |
|
| 42 |
You /could/ try turning sandbox off (in FEATURES). That's a bit dangerous |
| 43 |
by itself, but if you turn userpriv on at the same time, it should be |
| 44 |
fairly safe. YOu can try it but I'm guessing it'll still fail, as the |
| 45 |
portage user won't (for good reason!) have privs to delete the file either. |
| 46 |
|
| 47 |
If userpriv doesn't work, you can try without either sandbox or userpriv, |
| 48 |
just to be sure. HOWEVER, I'd be very sure I had a backup of that file |
| 49 |
and preferably my system first, just in case. Additionally, messing with |
| 50 |
glibc stuff is asking to see your system crash, so I'd not recommend |
| 51 |
running anything else critical during this test. Actually, I'd not |
| 52 |
recommend running it at all, without first checking bugzilla and filing a |
| 53 |
bug on it if necessary. If a toolchain/gcc dev tells you to try it without |
| 54 |
sandbox and userpriv, /then/ I'd feel a bit safer with it. I might |
| 55 |
personally try it here anyway, but I wouldn't feel right recommending that |
| 56 |
others try it. |
| 57 |
|
| 58 |
In any case, even if FEATURES="-sandbox userpriv" works, it's still worth |
| 59 |
checking to see if a bug has been filed and filing one yourself if not. |
| 60 |
If it's OK to do, the devs might simply disable sandbox checking for that |
| 61 |
file. However, that doesn't look to me like something it should be |
| 62 |
touching, in which case they need to figure out why it's happening and fix |
| 63 |
the problem, so others don't run into it. |
| 64 |
|
| 65 |
-- |
| 66 |
Duncan - List replies preferred. No HTML msgs. |
| 67 |
"Every nonfree program has a lord, a master -- |
| 68 |
and if you use the program, he is your master." Richard Stallman |
| 69 |
|
| 70 |
-- |
| 71 |
gentoo-amd64@g.o mailing list |
Archives