Folks,
I would like to use the nan.h and dlfcn.h header files with mingw;
however, they do not seem to be included in the source package. Does
anyone know where I can find them or have any ideas on how to replace
them?
Thanks,
Edmund

[ "japh" = "just another perl hack"]
Hello MinGW-List,
I have been up to more monkey-business ;-) and want to solicit feedback
from users about my latest production.
If one asks a question about "a bug" in gcc on this List or on the Cygwin List
(right Earnie?) one will often be asked to give the output of a command like
this one:
touch foo.c && gcc --verbose -c foo.c
- and the result looks like .. something messy (I was going to use a
tastelessly graphic digestive-system analogy ..). Some of us don't always get
away with not having our eyes cross in their sockets and a state of
unconciousness begin to come on us when we've been hacking for 12 hours
and we must then look at something like this, intently, trying to figure out if
it tells us where a problem lies ..
I've cobbled togwether a little Perl to make something readable (easy on
the eyes for us faint-hearted souls) out of that output. My system gives
this, tonight:
---- output --- cut here ----
Reading specs from D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs
gcc version 2.95.2 19991024 (release)
------------------------------------------------------------------------
D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\cpp.exe
------------------------------------------------------------------------
Shows us:
-D__GNUC__=2
-D__GNUC_MINOR__=95
-Di386
-D_WIN32
-DWIN32
-D__WIN32__
-D__MINGW32__=0.2
-D__MSVCRT__
-DWINNT
-D_X86_=1
-D__STDC__=1
-D__stdcall=__attribute__((__stdcall__))
-D_stdcall=__attribute__((__stdcall__))
-D__cdecl=__attribute__((__cdecl__))
-D__declspec(x)=__attribute__((x))
-D__i386__
-D_WIN32
-D__WIN32__
-D__WIN32__
-D__MINGW32__=0.2
-D__MSVCRT__
-D__WINNT__
-D_X86_=1
-D__STDC__=1
-D__stdcall=__attribute__((__stdcall__))
-D___stdcall__=__attribute__((__stdcall__))
-D__cdecl=__attribute__((__cdecl__))
-D__declspec(x)=__attribute__((x))
-D__i386
-D__WIN32
-D__WINNT
-D___stdcall=__attribute__((__stdcall__))
-Asystem(winnt)
-Acpu(i386)
-Amachine(i386)
-Acpu(i386)
-Amachine(i386)
-Di386
-D__i386
-D__i386__
GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
D:\MinGW32\gcc-2.95.2\include
D:\MinGW32\gcc-2.95.2\i386-mingw32msvc\include
D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\include
End of search list.
The following default directories have been omitted from the search path:
/gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include/g++-3
/usr/local/i386-mingw32/include
End of omitted list.
------------------------------------------------------------------------
GNU C version 2.95.2 19991024 (release) (i386-mingw32msvc) compiled by:
GNU C version 2.95.2 19991024 (release).
------------------------------------------------------------------------
-- end output --- cut here --
Does this seem like all the information that one normally wants to see? In
othe words, look at it (please) critically as if you were diagnosing a cc fatal
error that happened while building a package .. there are a few bits of text
removed (but that and line wrapping is not all it does; it importantly -- to
me -- 'collapses' redundant concatonated '../' pieces of paths) .. vis-a-vis the
standard unpretty gush output from gcc. I want to know if this comprises
satisfactorily complete output in the opinion of those more knowledgeable
than myself, before I release it ("it" being my little perl hack,
"gcc_spec_check.pl").
The program would be invoked like this BTW:
$ gcc_spec_check.p
- iow, very simple to "run".
TIA,
soren andersen