[Freeciv-Dev] Re: compile on windows and possible bug with map size

[Christian Stock <cstock@xxxxxxxxxxxxxx>]

Thanks for the neat explanation. In the end it was easy to fix. Like 
Andreas wrote earlier I just had to add the /MT option to the compiler! I 
tried the linker yesterday, which obviously didn't work. Thanks to your 
explanation I figured it out, and I even know now what /MT means and learnt 
something new about win single/multthread libs... :)
(On a side note, after adding /MT I really had to actively recompile 
everything, just hitting the F7 key wouldn't do).
The server compiles now, and does NOT crash! Now on to the client....

Thanks for the help!

Cheers, Christian


At 02:33 PM 25/06/2002 +0000, you wrote:
> On Tue, 25 Jun 2002 19:14:00 +1000, Christian Stock
> <cstock@xxxxxxxxxxxxxx> wrote:
>
> >Thanks for all the help!
> >
> >I fixed the config.h for msvc and it seems to work (I had to undefine a few
> >things).
> >
> >Added the HAVE_CONFIG_H as compile option, pretty easy, thanks for that.
> >
> >Replaced the S_ISREG with what's in the macro. Works fine... (stupid to
> >take the S_ISREG out of the stat.h in the first place, but oh well). Maybe
> >it would be good to insert a #ifdef W32_NATIVE and then replace the S_ISREG
> >with whats in the macro, or make a new #ifdef W32_MSVC...
> >
> >So, now I'm stuck with the last error _beginthreadex. I mostly worked it
> >out. MSVC includes a few default libs, one of them is libc.lib which is for
> >single threading. _beginthreadex is in the multi-thread lib libcmt.lib. So
> >I just had to exclude the libc.lib. Not too hard. However, now errno isn't
> >defined anymore. Probably it's in the libc.lib, but not in the libcmt.lib.
> >I wish M$ would stop doing this sort of brain damaged stuff. Any clues 
> on that?
> Might have ;-)
>
> Incremental compilers can occasionally fail to notice "insigificant"
> changes, especially to project settings. Methinks adding or removing
> /MT, or replacing a singletasking lib with a multitasking one, ought to
> cause a complete rebuild of everything - do so manually to be certain.
> If problem vanishes you've discovered a VC bug.
>
> The 'errno' definition has to change. What was a single "extern int" has
> to mutate into something different such that it supports multiple
> instances of 'errno', one per thread. The values differ but the
> relationship is identical to ::GetLastError() - each Win32 thread gets
> its own 'errno' which *it* sees as the one-and-only 'errno'.
> Consequently the declaration for 'errno' in <errno.h> will be
> conditionalised upon a macro and (almost certainly) mutate into a
> function. That function probably exists in libcmt.lib whereas libc.lib
> will have had storage only for a single directly accessed 'int'. The
> function is unlikely to be called errno(), there's probably an errno
> macro masking it (so your code doesn't have to change).
>
> If the problem persists, then desperation time. Pick a source that uses
> 'errno' and add this kind of thing at a reasonable place...
>
> #ifdef _MT
> # error OKI
> #else
> # error [choice swear word]
> #endif
>
> The _MT may/will be wrong (I got it from C++ Builder). Scan through VC
> <errno.h> and duplicate the expression it uses.
>
> >This really should be the last error, but then there's still a chance that
> >the server (once it's built) will just crash on me...
>
> All windows programs crash. It's a rule. I'm sure of it. ;-)
>
>
> --
> swamp-dog@xxxxxxxxxxxx