Mgnuc is compiling with no-ansi right? So that's correct then. <div class="gmail_quote">On Jun 5, 2013 7:10 AM, "Julien Fischer" <<a href="mailto:jfischer@opturion.com">jfischer@opturion.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, 5 Jun 2013, Julien Fischer wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, 4 Jun 2013, Tycho Luyben wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> stack_t is defined in linux/signal.h while it includes signal.h ; you're not supposed to include linux/signal.h at all I think. By just copy/pasting the stack_t definition into mercury_signal.h it compiles again, but then drops out on missing siginfo_t. That means i'm stuck as siginfo seems to be huge *and* seems to be included from signal.h and yet it cannot find it. Any ideas? </blockquote> There is a more general problem on Linux here (i.e not restricted to the arm-unknown-linux-gnueabi architecture). On my x86_64-unknown-linux-gnu box (Ubuntu 12.04), compiling the following program with gcc is fine: #include <ucontext.h> int main(void) { return 0; } whereas compiling it via the mgnuc script results in error message about stack_t not being defined. So, there seems to be some issue with the header files (or how Mercury is using them) on some Linux systems and / or with how the mgnuc script is invoking gcc. I will take a look into this. </blockquote> The above is down to mgnuc's use of GCC's -ansi option. However, Mercury's runtime should be compiled with mgnuc's --no-ansi (which should disable the use of GCC's -ansi) option enabled. Cheers, Julien. </blockquote></div>