https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
--- Comment #17 from Sascha Wilde <swi...@sha-bang.de> --- (In reply to David Malcolm from comment #16) > (In reply to Sascha Wilde from comment #10) > > (In reply to David Malcolm from comment #8) > > > It would be good to know exactly where that error message is being > > > emitted. > > > > > > If you add: > > > gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); > > > to the test code (e.g. immediately after the call to > > > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of > > > logging (see > > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) > > > > > > Can you attach the log you get please? > > > > With security.pax.mprotect.global=1 it produces no extra output. > > I'll attach the output produced when security.pax.mprotect.global is > > disabled. > > Thanks! I was wondering if the error message was: > (a) due to a problem dynamically linking libgccjit into the process, or > (b) a later problem with linking the code that libgccjit generates into > the process. > > Given that there's no extra log output at all with the protection flag, it > sounds like it's (a) - though you may run into a similar problem with (b) > if/when (a) gets solved. FWIW, the reason why I stumbled upon this problem is that I am testing the native compiling GNU Emacs branch[0] on the NetBSD system. (Which, by the way, can be build and works great once security.pax.mprotect.global is disabled) When security.pax.mprotect.global is enable the Emacs, linked with libgccjit can not be started at all, failing with the same error as the hello-world example. So this matches your analysis that the problem is triggered by dynamically linking libgccjit. [0] https://akrl.sdf.org/gccemacs.html
