>>> On 6 Mar 2010, at 13:57, Vincent Richomme wrote: >>> > If you really want to be pedantic, why don't you cast result from strdup > into const char*(type > of ivar_name) > > ivar->ivar_name = (const char *)strdup(name); > > > Anyway it doesn't solve clang error.
Ok I found it's because __STRICT_ANSI__ seems to be defined and in mingw include we get a #ifdef defined like this : #ifndef __STRICT_ANSI__ ... _CRTIMP char* __cdecl __MINGW_NOTHROW _strdup (const char*) __MINGW_ATTRIB_MALLOC; ... #ifndef _NO_OLDNAMES /* * Non-underscored versions of non-ANSI functions. They live in liboldnames.a * and provide a little extra portability. Also a few extra UNIX-isms like * strcasecmp. */ ... _CRTIMP char* __cdecl __MINGW_NOTHROW strdup (const char*) __MINGW_ATTRIB_MALLOC; ... #endif /* _NO_OLDNAMES */ #endif /* Not __STRICT_ANSI__ */ So strdup definition cannot be found. That's the kind of things that makes me use mingw-w64 instead of mingw but it might be a bit too early for GNUstep to switch. For now I have commented the #ifdef __STRICT_ANSI and I get of course another error : ./sendmsg2.c:3:10: fatal error: 'dlfcn.h' file not found #include <dlfcn.h> I have commented this include since you dont' use any of the dlxxx functions. Then I get : In file included from sendmsg.c:845: ./sendmsg2.c:5:1: error: thread-local storage is unsupported for the current target __thread id objc_msg_sender; Hum, mingw has released a new toolchain based on gcc-4.5 with Thread local storage but it's still in beta for now and is a bit broken. So now option are : 1) Wait for mingw people to fix their toolchain with TLS 2) Try to understand how GNUstep is designed and compile it on a mingw-w64 install Of course waiting is a lot simpler ;-) so I will keep you informed. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
