+++ This bug was initially created as a clone of Bug #379931 +++ In src_install, racket's Makefiles call at some point: $(MAKE) install-common-middle which calls: $(MAKE) lib-finish which calls: /var/tmp/portage/dev-scheme/racket-5.1.2/work/racket-5.1.2/src/lt/libtool --mode=finish "/usr/lib" which calls: PATH="$PATH:/sbin" ldconfig -n /usr/lib which results in: ACCESS DENIED UNLINK: /usr/lib/libbigloocalendar_es-3.6b.so ---------------------------------------------------------------------- Libraries have been installed in: /usr/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator run these commands: PATH="$PATH:/sbin" ldconfig -n /usr/lib - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- make[4]: Leaving directory `/var/tmp/portage/dev-scheme/racket-5.1.2/work/racket-5.1.2/src' make[3]: Leaving directory `/var/tmp/portage/dev-scheme/racket-5.1.2/work/racket-5.1.2/src' make[2]: Leaving directory `/var/tmp/portage/dev-scheme/racket-5.1.2/work/racket-5.1.2/src' env CFLAGS="-O2 -march=i686 -pipe -I/usr/lib/libffi-3.0.9/include -pthread -DMZ_DONT_USE_JIT" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -pthread" racket/racket3m -X "/var/tmp/portage/dev-scheme/racket-5.1.2/image//usr/lib/racket/collects" -N "raco setup" -l- setup --no-user --no-docs raco setup: bootstrapping from source... (raco setup snip) >> Completed installing racket-5.1.2 into /var/tmp/portage/dev-scheme/racket-5.1.2/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-22625.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: UNLINK S: deny P: /usr/lib/libbigloocalendar_es-3.6b.so A: /usr/lib/libbigloocalendar_es-3.6b.so R: /usr/lib/libbigloocalendar_es-3.6b.so C: ldconfig -n /usr/lib -------------------------------------------------------------------------------- So here is the point (many issues actually): Sandbox issue: I think this should not happened, but it did libbigloocalendar_es-3.6b.so no longer exists, the unlink call succeeded # ls -l /usr/lib/libbigloocalendar_es-3.6b.so ls: cannot access /usr/lib/libbigloocalendar_es-3.6b.so: No such file or directory why it should be: # ls /usr/lib/libbigloomultimedia_es-3.6b.so -l lrwxrwxrwx 1 root root 42 Aug 4 20:23 /usr/lib/libbigloomultimedia_es-3.6b.so -> bigloo/3.6b/libbigloomultimedia_es-3.6b.so Manually calling `ldconfig -n /usr/lib` restore a different link: # ldconfig -n /usr/lib # ls /usr/lib/libbigloocalendar_es-3.6b.so -l lrwxrwxrwx 1 root root 28 Aug 20 09:46 /usr/lib/libbigloocalendar_es-3.6b.so -> libbigloocalendar_eu-3.6b.so So can this be a dev-scheme/bigloo issue with its libraries too? I haven't try to emerge racket after unmerging bigloo, I'll try it later. Trying to emerge again racket fails at the same point, ldconfig -n /usr/lib keeps relinking the same libraries again and again, libtool issue? The work around that work for me is to remove the call to $(MAKE) lib-finish PS: Looking at the racket-5.1.1 build.log, it called ldconfig -n /usr/lib too, but I didn't get the sandbox violation, I don't know why...
ldconfig knows nothing about libtool. what you describe there sounds like the expected behavior (even if it's not optimal).
i've fixed this locally for x86_64. i'll need to look at the other targets we support ptrace on to see how to set syscall numbers and return values before i release this though.
i've verified the behavior on x86/hppa/x86_64. i thought i did more ptrace ports, but i guess i haven't committed those yet. makes it easier this way :). http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=19c9819364989b4831917c880af9a977beb5ce83
