quotable6

query

execstack

result

As far back as January 2014, but it was never bubbled upstream instead some folk just kvetched about the dyncall assembly code and did -Wl,-z,noexecstack
Yes. If you don't want to wait you can force it at linktime with-Wl,-z,noexecstack in the relevant portion of the makefile
Rakudo * will build there, with one caveat: the build fails first, then you can disable execstack on libmoar.so, try again, then it works. That's using rakudobrew.
Is it reasonable for the rakudo build environment to detect WSL and compile with -noexecstack in order to build more easily there?
Or do you prefer to just wait until MS has implemented execstack support ?
That promised link. The rakudo * / moarvm stuff is at the very end, the thread is about execstack in WSL in general: https://github.com/Microsoft/BashOnWindows/issues/286
i don't see execstack mentioned on the RT or on the github post?
Let me find the link again that talks about building moarvm and execstack
It's because it tries to use execstack in libmoar.so and yeah, no go on WSL
So if rakudobrew compiled libmoar with -noexecstack (and a couple other switches), this would likely work
To be clear Though, im not suggesting to detect the failure. I'm suggesting to detect WSL, compile without execstack (thats just an option to gcc), so that there is no failure
This is also emphatically not a bug in moar. It's reasonable to assume execstack is there when you detect an Ubuntu environment. That WSL is a partial implementation of Linux syscalls is an unexpected wrinkle. :)
You need `sudo execstack -c /usr/lib/libmoar.so`
huggable: win10 bash :is: sudo execstack -c /usr/lib/libmoar.so
IOninja, Added win10 bash as sudo execstack -c /usr/lib/libmoar.so
only the execstack was missing
what's the purpose of execstack?
from this site: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart which says to add these: -Wl,-z,noexecstack
I changed it so LDFLAGS=@ldflags@ -Wl -z noexecstack without knowing how to properly join things in make
you could try using "execstack -q" on the moarvm command and on any shared objects it needs, and "execstack -c" on any of them that say they require it, and see if things still work
(execstack -q will show the state of the "exec stack needed" flag, execstack -c will clear the flag)
how do I run that over the configure command? or do I have to go through and insert the execstack call over every command (or ??)?
it's not the configure command that matters here, you will have gotten moarvm installed before it can build rakudo (it does this early) so you'd find that and use the execstack command on it
so there's the flag that can set the "noexecstack" feature
iiuc we need execstack for dyncall or something?
ugexe: you don't know that, after fixing the noexecstack, who knows what exactly fails now
pmichaud, make install even on selinux enabled systems? http://danwalsh.livejournal.com/13716.html allow_execmem, allow_execstack, allow_execheap, allow_execmod -- textrel_shlib_t unconfined_execmem_exec_t java_exec_t mono_exec_t
Hey. I just installed moar (and nqp/rakudo/panda/some modules) with the executable stack bit turned off (linker option -z noexecstack). Stuff seems to work. Now I wonder, am I bound for failure? (Because there should be some reason for gcc to set that bit in the first place...)
noexecstack is a security feature, right?
i suspect it won't. in that case it'd be cool if we had detection for how to set "noexecstack" on different OS/compiler combinations :)
geekosaur: http://linux.die.net/man/8/execstack says the opposite
so if the libs on the build system had execstack enabled, the executable would be so flagged
but if the libs on the run system don't have execstack then the program doesn't actually need it