Mail Archives: cygwin/1997/12/06/23:26:38
Colin Peters wrote:
> The reason the function doesn't work without __cdecl__ is that it is
> getting name mangled like a C++ function (I think, see below). The header
> file should feature a pair of sequences like this around the _beginthread
> and other prototypes:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> ... function prototypes ...
>
> #ifdef __cplusplus
> }
> #endif
This is indeed included in the header file.
> The version of Mingw32 you are using might have a bug in that header. You
> could try downloading version 0.1.4 from my web page, or the latest
> snapshot if you feel brave (on second thought, if you download the latest
> snapshot only pull out the process.h header file, the new specs won't work
> with b18).
> Now that it occurs to me, what does that prototype look like? It should be
>
> unsigned long _beginthread (void (*pfuncStart)(void *), unsigned
> unStackSize, void* pArgList);
>
> It occurs to me that older versions of Mingw32 might have had an attempt
> to cdecl pfuncStart, which is unnecessary and may cause problems in some
> cases. Grab process.h out of 0.1.4 (I think) or the latest snapshot. Or
> just replace the prototype with the one given above.
Did so and this did indeed fix the problem (Yes!) but...
Now I can compile an object file correctly but I now am not able to link
correctly to _beginthread. ld returns error :
test.o(.text+0x3d):test.cc: undefined reference to `_beginthread(void (*)(void
*), unsigned int, void *)'
GCC.EXE: Internal compiler error: program ld got fatal signal 1
according to the source release of mingw32 this finction is provided by
crtdll.dll and is there for linked agenst libcrtdll.a. Howerev even after
explisitly linking agenst this library I was unable to make ld happy. My only
thought on the matter is that my test case was a console program and not a
"Windowed" program as of this letter I have yet to test it as such. It is also
interesting to note that the exact same program including _beginthread compiles
and runs nicley as a "c" program. which makes me suspicios that it has
something to do with the c++ compiler it's self and not mingw32.
> If none of this fixes things it might be a bug in the C++ parser (I doubt
> it though). It works fine for me using Mumit Khan's Mingw32-native version
> of EGCS. I can't test against b18 right now (since it isn't on my disk
> drive).
>
> Good luck,
> Colin.
I am in the prosses of downloading this as I type in hope that it will solve my
problems. Thank you for all your help and hard work on this process (Pun
Intended)
Thanks
John Miller
<jfmiler AT polymail DOT calpoly DOT edu>
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -