cd /var/tmp/portage/dev-lisp/gcl-2.6.7-r2/image//usr/lib/gcl-2.6.7/unixport && \ mv saved_ansi_gcl temp && \ echo '(reset-sys-paths "/usr/lib/gcl-2.6.7/")(si::save-system "saved_ansi_gcl")' | ./temp && \ rm -f temp GCL (GNU Common Lisp) 2.6.7 ANSI Jan 8 2007 21:16:44 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /var/tmp/portage/dev-lisp/gcl-2.6.7-r2/temp/ > NIL >/bin/sh: line 3: 1780 Done echo '(reset-sys-paths "/usr/lib/gcl-2.6.7/")(si::save-system "saved_ansi_gcl")' 1781 Segmentation fault | ./temp make[1]: *** [install1] Error 139 make[1]: Leaving directory `/var/tmp/portage/dev-lisp/gcl-2.6.7-r2/work/gcl-2.6.7' make: *** [install] Error 2 !!! ERROR: dev-lisp/gcl-2.6.7-r2 failed. Call stack: ebuild.sh, line 1593: Called dyn_install ebuild.sh, line 1036: Called src_install gcl-2.6.7-r2.ebuild, line 68: Called die What's odd is that the only thing that's changed since the last time I installed it is the ebuild itself; the change from SANDBOX_ON=0 to RESTRICT="sandbox". I'm inclined to think that this is the gcl/sandbox interaction bug showing up again, especially as I haven't been able to reproduce the bug outside sandbox. Could RESTRICT="sandbox" be failing to work properly?
Well, FEATURES=-sandbox emerge -1 gcl works. I hate being right.
ccing vapier 'cos it was his commit. I don't think RESTRICT=sandbox ever worked, and it doesn't seem to be used in the tree; the only mention Google has is a gentoo-user-de post asking why it wasn't working.
then talk to the portage team and get it working ... clobbering FEATURES is wrong
s/FEATURES/SANDBOX_ON/
Yep, that's what bug 161045 is for.
(In reply to comment #3) > then talk to the portage team and get it working Would you revert your "fix" meanwhile? Because it's plain broken now due to the invalid restrict you've stuck in there, don't see how this helps anyone. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/gcl/gcl-2.6.7-r2.ebuild?r1=1.2&r2=1.3
Created attachment 106522 [details, diff] alloc-sandbox-fix.patch Patch.
Note, the segv is: Program received signal SIGSEGV, Segmentation fault. 0x4034d486 in __realpath (name=0x8fff000 "/var/db/aliases.db", resolved=0x9001000 <Address 0x9001000 out of bounds>) at canonicalize.c:98 98 rpath[0] = '/'; #0 0x4034d486 in __realpath (name=0x8fff000 "/var/db/aliases.db", resolved=0x9001000 <Address 0x9001000 out of bounds>) at canonicalize.c:98 #1 0x4001f646 in init_env_entries (prefixes_array=0x400273fc, prefixes_num=0x40027400, env=0x400238db "SANDBOX_PREDICT", prefixes_env=0xbfb69e22 "/var/tmp/portage/dev-lisp/gcl-2.6.7-r2/homedir/.:/usr/lib/python2.0/:/usr/lib/python2.1/:/usr/lib/python2.2/:/usr/lib/python2.3/:/usr/lib/python2.4/:/usr/lib/python2.5/:/usr/lib/python3.0/:/var/db/ali"..., warn=1) at sandbox-1.2.18.1/src/libsandbox.c:1064 #2 0x4002088c in before_syscall (func=0x400237e1 "open_rd", file=0x8394440 "/var/tmp/portage/dev-lisp/gcl-2.6.7-r2/image/usr/lib/gcl-2.6.7/unixport/temp") at sandbox-1.2.18.1/src/libsandbox.c:1514 #3 0x4002197e in open_DEFAULT ( pathname=0x8394440 "/var/tmp/portage/dev-lisp/gcl-2.6.7-r2/image/usr/lib/gcl-2.6.7/unixport/temp", flags=<value optimized out>) at sandbox-1.2.18.1/src/libsandbox.c:1551 #4 0x08088ac2 in unexec ( new_name=0x9001000 <Address 0x9001000 out of bounds>, old_name=0x1003 <Address 0x1003 out of bounds>, data_start=1073902592, bss_start=0, entry_address=0) at unexelf.c:672 #5 0x08089d3e in Lsave () at save.c:12 #6 0x0805293d in siLsave_system () at main.c:977 #7 0x080d8353 in eval (form=0x8522800) at eval.c:1090 #8 0x080d85e5 in fLeval (x0=0x8ec7dc8) at eval.c:1178 #9 0x08056c70 in IapplyVector (fun=0x853de24, nargs=1, base=0x839b5e4) at nfunlink.c:229 #10 0x080d8b09 in funcall (fun=<value optimized out>) at eval.c:190 #11 0x0817e3a7 in LI1 () at gcl_top.c:140 #12 0x080d7743 in quick_call_sfun (fun=0x853d000) at eval.c:117 #13 0x080d8a64 in funcall (fun=<value optimized out>) at eval.c:178 #14 0x08056cc7 in IapplyVector (fun=0x853d000, nargs=0, base=0xbfb6809c) at nfunlink.c:239 #15 0x080d75e5 in fLfuncall (fun=0x853d000) at eval.c:1140 #16 0x08056c70 in IapplyVector (fun=0x853de4c, nargs=1, base=0x839b5b4) at nfunlink.c:229 #17 0x080d8b09 in funcall (fun=<value optimized out>) at eval.c:190 #18 0x080d822d in eval (form=0x8522800) at eval.c:1092 #19 0x080d8827 in funcall (fun=<value optimized out>) at eval.c:327 #20 0x080d822d in eval (form=0x8522800) at eval.c:1092 #21 0x080d8827 in funcall (fun=<value optimized out>) at eval.c:327 #22 0x08053324 in main (argc=1, argv=0x0, envp=0x0) at main.c:373
(In reply to comment #6) > (In reply to comment #3) > > then talk to the portage team and get it working > > Would you revert your "fix" meanwhile? Because it's plain broken now due to the > invalid restrict you've stuck in there, don't see how this helps anyone. > i strongly agree with jakub as neither gcl-2.6.7(-r(1|2))? works for me out of the box (see bug 125753 and bug 156795)
Re the patch: I'm not entirely sure why it works. I've asked on the mailing list: http://lists.gnu.org/archive/html/gcl-devel/2007-01/msg00006.html but no response as yet. If I don't get a response soon I'll file a bug on upstream's tracker.
(In reply to comment #7) I can confirm this patch works - at least gcl installs for me now. Thanks!
(In reply to comment #11) > (In reply to comment #7) > I can confirm this patch works - at least gcl installs for me now. Thanks! > Unfortunately it appears to break sci-mathematics/maxima: Finished loading /var/tmp/portage/sci-mathematics/maxima-5.11.0/work/maxima-5.11.0/src/init-cl.lisp ; - Providing system maxima .bss shrank when undumping??? make[1]: *** [binary-gcl/maxima] Error 1 I haven't got any response from the mailing list; I'll try putting a smaller testcase together.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #7) > > I can confirm this patch works - at least gcl installs for me now. Thanks! > > > > Unfortunately it appears to break sci-mathematics/maxima: > > Finished loading > /var/tmp/portage/sci-mathematics/maxima-5.11.0/work/maxima-5.11.0/src/init-cl.lisp > ; - Providing system maxima > .bss shrank when undumping??? > make[1]: *** [binary-gcl/maxima] Error 1 > > I haven't got any response from the mailing list; I'll try putting a smaller > testcase together. >
Sorry for the previous "test comment". I believe the reason for the error in #12 is that maxima-5.11 was installed. It is installe if ACCEPT_KEWORDS="~x86" is used. I had the same problem as described above and here is what works for me. 1) emerge maxima (this way it installs 5.9.1) 2) ACCEPT_KEWORDS="~x86" emerge imaxima (it breaks at gcl installation) 3) ACCEPT_KEWORDS="~x86" USE="readline ansi" FEATURES=-sandbox emerge gcl 4) ACCEPT_KEWORDS="~x86" emerge breqn 5) ACCEPT_KEWORDS="~x86" emerge --nodeps imaxima you also may need gnuplot and maxima works under emacs!!! (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #7) > > > I can confirm this patch works - at least gcl installs for me now. Thanks! > > > > > > > Unfortunately it appears to break sci-mathematics/maxima: > > > > Finished loading > > /var/tmp/portage/sci-mathematics/maxima-5.11.0/work/maxima-5.11.0/src/init-cl.lisp > > ; - Providing system maxima > > .bss shrank when undumping??? > > make[1]: *** [binary-gcl/maxima] Error 1 > > > > I haven't got any response from the mailing list; I'll try putting a smaller > > testcase together. > > >
ok so what's the fix?
(In reply to comment #12) > Unfortunately it appears to break sci-mathematics/maxima: > > Finished loading > /var/tmp/portage/sci-mathematics/maxima-5.11.0/work/maxima-5.11.0/src/init-cl.lisp > ; - Providing system maxima > .bss shrank when undumping??? > make[1]: *** [binary-gcl/maxima] Error 1 Well, that was a non-starter. See bug 164656 for a totally different approach.
(In reply to comment #15) > ok so what's the fix? The current workaround is to set SANDBOX_ON=0, either in the ebuild or in /etc/portage/bashrc (see portage(5)): # http://bugs.gentoo.org/show_bug.cgi?id=161041 [[ "$CATEGORY/$PN" == dev-lisp/gcl ]] \ && export SANDBOX_ON=0
(In reply to comment #17) > (In reply to comment #15) > > ok so what's the fix? > > The current workaround is to set SANDBOX_ON=0, either in the ebuild or in > /etc/portage/bashrc (see portage(5)): > > # http://bugs.gentoo.org/show_bug.cgi?id=161041 > [[ "$CATEGORY/$PN" == dev-lisp/gcl ]] \ > && export SANDBOX_ON=0 > that does the trick too: # FEATURES="-sandbox" emerge -av gcl
*** Bug 167320 has been marked as a duplicate of this bug. ***
# FEATURES='-sandbox -usersandbox' emerge -1 gcl is needed for those who have usersandbox enabled (-sandbox alone doesn't help).
Is this still open??
(In reply to comment #21) > Is this still open?? It looks still open to me, as its status is NEW, and it should still be open, as I encountered it again today when new portage wanted to remerge many things.
i added back the workaround since Ed has properly diagnosed the issue and we can get sandbox fixed ... see Bug 164656 for follow up
*** Bug 190950 has been marked as a duplicate of this bug. ***
