Summary: | app-emulation/wine-1.5.21 - configure: checking for -lGL... ./conftest: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Operation not permitted | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hcaulfield57 |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | synamics, wine, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
hcaulfield57
2013-01-08 01:02:32 UTC
Created attachment 334754 [details]
build.log
> checking for -lGL... ./conftest: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Operation not permitted
not found
It appears that your hardened setup is blocking executables that link to your opengl library.
@hardened, @x11, what should be the fix, and is it something that needs to be done on the wine ebuild side?
What video driver are you useing? Not sure if this is the same issue but something somewhat similar-seeming just happened to me on 1.5.23-r1 (slightly later in the build process); I don't harden and the problem persisted in vmware, which rules out both as likely culprits. However, I was able to build after turning off sandbox, so perhaps this is some kind of 64/32-wine vs sandbox problem? Here is the output I can gather from my similar-ish-seeming build failure: if I capture everything in a log via # ( emerge -1 wine --color=n 2>&1 ) 2>&1 > /tmp/winebuild.log -- make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine32/dlls/acledit' config.status: creating dlls/aclui/Makefile make[1]: Entering directory `/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine32/dlls/aclui' ../../tools/makedep -C/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine-1.5.23/dlls/aclui -S/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine-1.5.23 -T../.. aclui_main.c /usr/lib32/libsandbox.so(+0xac04)[0xf76aac04] /usr/lib32/libsandbox.so(+0xacb1)[0xf76aacb1] /usr/lib32/libsandbox.so(+0x3fb9)[0xf76a3fb9] /usr/lib32/libsandbox.so(+0x422d)[0xf76a422d] /usr/lib32/libsandbox.so(fopen64+0x78)[0xf76a8b98] ../../tools/makedep[0x804a401] ../../tools/makedep[0x8048b89] /lib32/libc.so.6(__libc_start_main+0xf5)[0xf750c595] ../../tools/makedep[0x8048d09] /proc/27410/cmdline: ../../tools/makedep -C/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine-1.5.23/dlls/aclui -S/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine-1.5.23 -T../.. aclui_main.c make[1]: *** [depend] Aborted (core dumped) make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine32/dlls/aclui' make: *** [dlls/aclui/__depend__] Error 2 * ERROR: app-emulation/wine-1.5.23-r1 failed (configure phase): * emake failed * -- But, everything still doesn't get into the log. Amazingly, something still escapes from my shell redirection and spills onto the console (that's the first time I've /ever/ seen anything leak from this "( foo 2>&1 ) 2>&1" bash construct, I use it all the time!): (null)*(null) ../../sandbox-2.6/libsandbox/libsandbox.c:check_syscall():879: failure (Value too large for defined data type): (null)*(null) ISE: abs_path: (null) res_path: /var/tmp/portage/app-emulation/wine-1.5.23-r1/work/wine32/include/config.h Well I saw something similar happen in gcc47 now. So, my issue is starting to look like a sandbox (hence, portage) issue affecting complex multilib ebuilds -- and perhaps not specifically a wine problem. Notably, I also have a pretty different setup with portage 2.2 and ~amd64 everything... So whether or not the reported issue stems from the same root cause as mine is not at all clear (I'm really just making a stab in the dark). Can you try disabling sandbox/usersandbox in your FEATURES, hcaulfield57? Well, anything at /var/log/messages? If grsecurity blocked anything it should be listed here. Feel free to reopen when there is info to give. |