Re: libobjc2 on windows

[Vincent Richomme]

>>> 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.