[PATCH] FOX configure for MinGW32

[Anders F Björklund]

Seemed like you couldn't configure and build for
MinGW32 with fox-1.7, like you could with fox-1.6 ?

It had all the X11 libraries hardcoded, so I added the
Win32 libraries and also patched some missing symbols...
(these were reported earlier too, but didn't see a fix)
Cross-compiles fine now, and runs with Wine or Windows.

--anders

PS. UI selection could definitely need something better
than just keying of whether "WIN32" is defined or not ?




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp-5]

On Thursday 05 November 2009, Anders F Björklund wrote:
>
> Seemed like you couldn't configure and build for
> MinGW32 with fox-1.7, like you could with fox-1.6 ?

I've switched to the newest autoconf version in 1.7, and
old stuff didn't make it through.

> It had all the X11 libraries hardcoded, so I added the
> Win32 libraries and also patched some missing symbols...
> (these were reported earlier too, but didn't see a fix)
> Cross-compiles fine now, and runs with Wine or Windows.
>
> --anders
>
> PS. UI selection could definitely need something better
> than just keying of whether "WIN32" is defined or not ?

It suffices.
 


Incidentally, I don't like the:

        #include <Windows.h>

in the patch.  


No platform-headers are to be included into heades that FOX application
programs can see, because application programs that use FOX do not
depend on platform-dependent headers at all (e.g. don't include X11 or
Windows header files).  This prevents lots of hassles.

Do you see a way to do without?


                - Jeroen

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp-5]

On Thursday 05 November 2009, Anders F Björklund wrote:

>
> Seemed like you couldn't configure and build for
> MinGW32 with fox-1.7, like you could with fox-1.6 ?
>
> It had all the X11 libraries hardcoded, so I added the
> Win32 libraries and also patched some missing symbols...
> (these were reported earlier too, but didn't see a fix)
> Cross-compiles fine now, and runs with Wine or Windows.
>
> --anders
>
> PS. UI selection could definitely need something better
> than just keying of whether "WIN32" is defined or not ?
>
>

Perhaps its better to change the FXAtomic as follows:

OLD:


  /// Set variable to v; return old value
  inline FXint set(FXint v){
#if defined(WIN32)
    return InterlockedExchange((LONG*)&val,v);
#elif (defined(__GNUC__) || defined(__ICC)) && (defined(__i386__) || defined(__x86_64__))
    FXint ret=v;
    __asm__ __volatile__("lock\n\t"
                         "xchgl %0,%1\n\t" : "=r" (ret) : "m" (val), "0" (ret) : "memory");
    return ret;
#else
    FXint ret=val;
    val=v;
    return ret;
#endif
    }


NEW:


  /// Set variable to v; return old value
  inline FXint set(FXint v){
#if (defined(__GNUC__) || defined(__ICC)) && (defined(__i386__) || defined(__x86_64__))
    FXint ret=v;
    __asm__ __volatile__("lock\n\t"
                         "xchgl %0,%1\n\t" : "=r" (ret) : "m" (val), "0" (ret) : "memory");
    return ret;
#elif defined(WIN32)
    return InterlockedExchange((LONG*)&val,v);
#else
    FXint ret=val;
    val=v;
    return ret;
#endif
    }


[etc]

I assume this might be better since if we're using GCC + x86 [-64 ] then we want the
inlined GCC assembly version and not the function call.

Or am I wrong here?


                - Jeroen




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Anders F Björklund]

Jeroen van der Zijp wrote:

> I assume this might be better since if we're using GCC + x86 [-64 ]  
> then we want the
> inlined GCC assembly version and not the function call.
>
> Or am I wrong here?

Maybe, I just know that those 4 functions were missing from
the winbase.h of the MinGW that I used even if the others
were there. Possibly they were added in a later Windows SDK
or something, saw* someone mention that using "NT5" also worked ?

* http://sourceforge.net/mailarchive/message.php?
msg_name=a275e6d00909282157k10e74a1ft9662caca34e57638%40mail.gmail.com

--anders


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Anders F Björklund]

Jeroen van der Zijp wrote:

>> PS. UI selection could definitely need something better
>> than just keying of whether "WIN32" is defined or not ?
>
> It suffices.

It gets really annoying if one is trying to add a
third platform or something, with the UNIX vs X11...

> Incidentally, I don't like the:
>
> #include <Windows.h>
>
> in the patch.

Me neither, but that's where the intrinsics were...
(possibly using <Winbase.h> and _InterlockedAdd etc)

> No platform-headers are to be included into heades that FOX  
> application
> programs can see, because application programs that use FOX do not
> depend on platform-dependent headers at all (e.g. don't include X11 or
> Windows header files).  This prevents lots of hassles.

Sounds like a good way to handle it, I agree.
But "LONG" and the "Interlocked*" were missing ?

> Do you see a way to do without?

Well, I suppose you mean as aside from moving them
from the inlined headers to the compiled source ?

You could move all of the Windows intrinsics and
the assembler to some helper function and inline
the call to that instead ? Or maybe you *could*
switch them over to use _Interlockedxxx instead ?

#include <intrin.h>
#pragma intrinsic(_InterlockedAnd)

--anders


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp-5]

On Thursday 05 November 2009, Anders F Björklund wrote:

> Jeroen van der Zijp wrote:
>
> > I assume this might be better since if we're using GCC + x86 [-64 ]  
> > then we want the
> > inlined GCC assembly version and not the function call.
> >
> > Or am I wrong here?
>
> Maybe, I just know that those 4 functions were missing from
> the winbase.h of the MinGW that I used even if the others
> were there. Possibly they were added in a later Windows SDK
> or something, saw* someone mention that using "NT5" also worked ?

I changed the order of #ifdef testing.  This means that if you're
GCC + x86[-64], it'll go with the inlines, regardless of underlying
operating system.  This is appropriate since this is not operating
system dependent, but compiler/architecture dependent.

It'll check WIN32 after the GCC/(x86,x86-64) check.


Now, there may still be an issue of having declarations for these API's
on WIN32; FOX itself doesn't use FXAtomic (only parallel programs would
even need to consider them) so it could be I have simply not noticed a
problem that exists.

(None of this affects MINGW32, btw).



        Cheers,


                                - Jeroen




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp-5]

On Thursday 05 November 2009, Anders F Björklund wrote:

> Jeroen van der Zijp wrote:
>
> >> PS. UI selection could definitely need something better
> >> than just keying of whether "WIN32" is defined or not ?
> >
> > It suffices.
>
> It gets really annoying if one is trying to add a
> third platform or something, with the UNIX vs X11...
>
> > Incidentally, I don't like the:
> >
> > #include <Windows.h>
> >
> > in the patch.
>
> Me neither, but that's where the intrinsics were...
> (possibly using <Winbase.h> and _InterlockedAdd etc)

One could say (for now) if you need them, include Windows.h yourself;
this is obviously that needs fixing since it isn't an acceptable
solution....

> > No platform-headers are to be included into heades that FOX  
> > application
> > programs can see, because application programs that use FOX do not
> > depend on platform-dependent headers at all (e.g. don't include X11 or
> > Windows header files).  This prevents lots of hassles.
>
> Sounds like a good way to handle it, I agree.
> But "LONG" and the "Interlocked*" were missing ?

Code compiles unless you actually flesh out FXAtomic in
your own code; only then would calls be generated; just including
it but not using them would not affect anyone.


> > Do you see a way to do without?
>
> Well, I suppose you mean as aside from moving them
> from the inlined headers to the compiled source ?

That would be one way.  Inside FOX implementation we *do* have
the Windows.h headers available.

Alternatively we could furnish our own declarations. I'm inclined
to prefer the first option, however.

> You could move all of the Windows intrinsics and
> the assembler to some helper function and inline
> the call to that instead ? Or maybe you *could*
> switch them over to use _Interlockedxxx instead ?

If there will be an "FXAtomic.cpp" inside the library,
then we can have whatever #ifdef ratnest is necessary to
get to the most efficient implementation.

I feel that this is probably the way to go:- implement
FXAtomic in terms of a few additional API's that live
in the library.  It also gets the ugliness out of the header
files.

Another issue is if FXAtomicInt (etc) should even be a class;
I'm thinking perhaps it shouldn't...


                - Jeroen



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Niall Douglas]

On 5 Nov 2009 at 15:53, Jeroen van der Zijp wrote:

> I assume this might be better since if we're using GCC + x86 [-64 ] then we want the
> inlined GCC assembly version and not the function call.
>
> Or am I wrong here?

On GCC if you'd like to be portable too (taken from TnFOX's
FXAtomicInt):

QMUTEX_INLINEI int FXAtomicInt::cmpXI(int compare, int newval)
throw()
{
#ifdef __GNUC__
        int myret;
#ifdef USE_X86
        __asm__ __volatile__ (
#ifdef FX_SMPBUILD
                "pause\n\tlock/cmpxchgl %2,(%1)"
#else
                "pause\n\tcmpxchgl %2,(%1)"
#endif
                : "=a" (myret) : "r" (&value), "r" (newval), "a" (compare));
#else
        while(__gnu_cxx::__exchange_and_add((_Atomic_word *) &lock, 1))
__gnu_cxx::__atomic_add((_Atomic_word *) &lock, -1);
        myret=value;
        if(value==compare)
                value=newval;
        __gnu_cxx::__atomic_add((_Atomic_word *) &lock, -1);
#endif
        return myret;
#elif defined(USE_WINAPI)
        return _InterlockedCompareExchange((PLONG) &value, newval, compare);
#endif
}

Those __gnu_cxx:: functions could actually replace all hand coded
assembler in GCC - moreover, they're portable too.

HTH,
Niall




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp-5]

On Friday 06 November 2009, Niall Douglas wrote:

> On 5 Nov 2009 at 15:53, Jeroen van der Zijp wrote:
>
> > I assume this might be better since if we're using GCC + x86 [-64 ] then we want the
> > inlined GCC assembly version and not the function call.
> >
> > Or am I wrong here?
>
> On GCC if you'd like to be portable too (taken from TnFOX's
> FXAtomicInt):
>
> QMUTEX_INLINEI int FXAtomicInt::cmpXI(int compare, int newval)
> throw()
> {
> #ifdef __GNUC__
> int myret;
> #ifdef USE_X86
> __asm__ __volatile__ (
> #ifdef FX_SMPBUILD
> "pause\n\tlock/cmpxchgl %2,(%1)"
> #else
> "pause\n\tcmpxchgl %2,(%1)"
> #endif
> : "=a" (myret) : "r" (&value), "r" (newval), "a" (compare));
> #else
> while(__gnu_cxx::__exchange_and_add((_Atomic_word *) &lock, 1))
> __gnu_cxx::__atomic_add((_Atomic_word *) &lock, -1);
> myret=value;
> if(value==compare)
> value=newval;
> __gnu_cxx::__atomic_add((_Atomic_word *) &lock, -1);
> #endif
> return myret;
> #elif defined(USE_WINAPI)
> return _InterlockedCompareExchange((PLONG) &value, newval, compare);
> #endif
> }
>
> Those __gnu_cxx:: functions could actually replace all hand coded
> assembler in GCC - moreover, they're portable too.

I have tried to use the compiler builtins before, and didn't have much
luck with them.

First, it appears that you have to be extremely careful with which CPU
architecture you're generating code for.  If your compiler is set to
"vanilla" x86 mode, then it won't generate locking versions.

Even on x86-64, I have found the builtins to be flawed.  The inline
assembly is more reliable.  I found this problem executing on dual
quad-core machines where locking actually involves bus cycles between
processors.  Stuff appeared to work on single processor machines.

Second, the builtins don't seem to be inlined in all cases.

This is why I'm not using the builtins.



                                - Jeroen
 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users