[Mono-list] Compile error with current cvs

Gonzalo Paniagua Javier gonzalo@ximian.com
03 Feb 2003 17:15:35 +0100

El lun, 03-02-2003 a las 16:17, Lluis Sanchez escribió:
> configure:6525:
> gcc -mno-cygwin -E -I/home/Lluis/install/include -DGC_WIN32_THREADS -DWIN32_
> THREADS conftest.c >/dev/null 2>conftest.out
> In file included from configure:6521:
> /home/Lluis/install/include/gc/gc.h:61:1: warning: "GC_WIN32_THREADS"
> redefined
> conftest.c:1:1: warning: this is the location of the previous definition
> configure: failed program was:
> #line 6520 "configure"
> #include "confdefs.h"
> #include <gc/gc.h>
> This problem can be solved by commenting the #define GC_WIN32_THREADS in
> gc.h. Then, it compiles.
> On the other hand, the script autogen.sh does not select the stable version
> of autoconf, so when it is not executed through mono-build-w32.sh, it uses
> the devel version to generate the configure script. This script does not
> fail to detect gc.h as far as CPPFLAGS is set to my install/include
> directory. However, the libtool script generated by this configure script is
> unable to link the jit, since it generates all those "undefined reference"
> errors.
> So to compile using autogen.h I had to include this in the script:
> CPPFLAGS="$CPPFLAGS -I/home/Lluis/install/include"
> LDFLAGS="$LDFLAGS -L/home/Lluis/install/lib"
> export CPPFLAGS
> export LDFLAGS
> if [ ! -z "${AUTO_STABLE}" -o -e /usr/autotool/stable ]; then
> export AUTO_STABLE=${AUTO_STABLE:-/usr/autotool/stable}
> fi
> Well, I've been able to compile and install... and now I get this when error
> when running mono:
> ** ERROR **: file jit.c: line 4101 (mono_get_lmf_addr): should not be
> reached
> But that's another problem ...

This is the problem that I fixed when I added -DWIN32_THREADS. Sometimes
(i didn't investigate further) the GC_API #define wasn't being defined
properly (lacked dllimport) because WIN32_THREADS was not always defined
(!?). This causes a SIGSEGV when mono runtime accesses GC variables such
as GC_finalize_on_demand.

If we fix the problem without using -DWIN32_THREADS... Can you check if
defining _DLL and removing WIN32_THREADS work?

Btw, I'm using gc6.1 headers and dll and didn't run into the problems
you have.