Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 53595 - Sandbox Access Violation while upgrading to gettext-0.12.1
Summary: Sandbox Access Violation while upgrading to gettext-0.12.1
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: Sparc Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-10 17:17 UTC by stephen
Modified: 2004-06-10 18:31 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stephen 2004-06-10 17:17:58 UTC
When I try to emerge -u gettext I get the following:
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-sys-devel_-_gettext-0.12.1-6924.log"

unlink:    /usr/lib/cf20417/conftest9012345
unlink:    /usr/lib/cf20417/conftest9012346
--------------------------------------------------------------------------------

The contents of the file are the same as the above two failed unlink messages.

Reproducible: Always
Steps to Reproduce:
1. emerge -u gettext

Actual Results:  
It appeared to do the make, and even the make install, but when it failed to
unlink the files it mentioned, it didn't update whatever was necessary for a
subsequent emerge -up gettext to reveal that it was up to date.

Expected Results:  
It should have completely installed the newest version of gettext, removed the
files it mentioned, and then did whatever it needed to satisfy portage so that
an emerge -up gettext would reveal that it was up to date.
Comment 1 stephen 2004-06-10 18:31:36 UTC
Now I feel stupid :)  The problem was that I moved /usr to a sub-directory of another partition and symlinked it back to /usr a while back.  Now the relative paths in /usr/bin seem to be pointing to the wrong location, so the invocation of /usr/bin/unlink that should have called /bin/unlink was failing.  When /bin was in the path before /usr/bin and ulink was invoked manually it would of course work.  But when programs specifically called /usr/bin/unlink it failed for certain working directories.  

By changing the links from ../../whatever to /bin/whatever it fixed the problem.