On Tuesday 18 August 2009, David Lim wrote:
> Hello Jeroen,
>
> This is a feedback. I do not know if I have missed out anything.
> Sorry for the lengthy email. I know you have lots of emails from everyone.
>
> Fox Tool Kit v1.7.19 (Windows)
> Compile on Windows XP with SP3
> Using CodeBlock IDE with MinGW <--- no problem Complete with Calculator
> running
> Using CodeBlock IDE with Visual C++ (refer to attach picture)
> Using CodeBlock IDE with BorlandC++ 5.5 (refer to attach picture)
>
>
>
> CodeBlock with MinGW 3.15
> -------------------------------
> 1) I Installed CodeBock with MinGW
> 1.2) Compile successfully with Calculator running on Windows XP.
> 2) Try compiling using VC studio 2005. The foxlib cannot be compiled
> (Cannot find function strtoll(). Should there be an include for
> strtoll() somewhere in FXString.cpp, see picture)
Probably, the flag HAVE_STRTOLL was set when it shouldn't have been. If you
set don't set it, FOX provides its own copy of strtoll and strtoull.
> 3) Try compiling using Borland BC 5.5. The foxlib cannot be compiled on
> CodeBloc/MingGW. line 450
Make sure the flags are set properly. We have trouble with the "LL" suffix
to generate 64-bit integer constants.
AFAIK, my own Borland C++ makefile should compile things properly. Perhaps
some flags are set differently by CodeBlock.
> 3.1) Whatever I do... add blank lines to move the codes down. Assign the
> value as 1. Remove the comment lines.... The error reported by the IDE
> is still line 450.
> 3.1.1) Something not quite right with CodeBlock and MinGW. The least it
> should report is the error line has changed. May be need to be saved two
> times or more
> before the file is re-compiled.
>
> Compile with Borland Builder 5.0
> ----------------------------------
> 4) Try compiling using Borland BC Builder 5 IDE. The foxlib cannot be
> compiled. line 450
> 4.1) Adding blank lines... moves the error line number accordingly. This
> is right compared to CodeBlock/MingGW/BC5.5
> 4.2) By removing one 'L' from 9223372036854775807LL. Managed to continue
> compilation. (see below)
>
> #if !defined(WIN32) || defined(__CYGWIN__) || defined(__MINGW32__) ||
> defined(__SC__) || defined(__BCPLUSPLUS__)
> /// A time in the far, far future
> //const FXTime forever=9223372036854775807LL;
> const FXTime forever=9223372036854775807L;
> #else
> /// A time in the far, far future
> const FXTime forever=9223372036854775807L;
> #endif
Well, the question is if replacing the "LL" with "L" gives us the same
64-bit constant? Because there's a risk that the compiler may give
us a truncated 32-bit value then assign that to the 64-bit variable.
> Is the '#' in line35 Makefile.bc an acceptable character in the define?
> (#-DHAVE_PNG_H)
> -DFOX_BIGENDIAN=0 -DNDEBUG -D_WINDOWS -DWIN32 -DUNICODE -DHAVE_GL_H
> -DHAVE_GLU_H -DHAVE_VSSCANF #-DHAVE_PNG_H -DHAVE_JPEG_H -DHAVE_TIFF_H
> -DXMD_H
>
> Removed the '#' to continue
Good question. Never noticed a problem with it before. Perhaps it depends
on what shell actually executes the line.
> In FXStat.cpp, I have replaced LL with L just to test the compilation
> on Builder 5.0
>
> #ifdef WIN32
> // Convert 100ns since 01/01/1601 to ns since 01/01/1970
> static inline FXTime fxfiletime(FXTime ft){
> #if defined(__CYGWIN__) || defined(__MINGW32__) || defined(__SC__) ||
> defined(__BCPLUSPLUS__)
> // return (ft-116444736000000000LL)*100LL;
> return (ft-116444736000000000LL)*100L;
> #else
> return (ft-116444736000000000L)*100L;
> #endif
> }
> #endif
>
> I have removed -DHAVE_TIFF... as I do not have the tiff files in my computer
>
> In strtoll.cpp, I have replaced LL with L just to test the compilation
> on Builder 5.0
> #ifndef ULLONG_MAX
> //#define ULLONG_MAX 18446744073709551615ULL
> #define ULLONG_MAX 18446744073709551615UL
> #endif
> #ifndef LLONG_MAX
> //#define LLONG_MAX 9223372036854775807LL
> #define LLONG_MAX 9223372036854775807L
> #endif
> #ifndef LLONG_MIN
> //#define LLONG_MIN (-LLONG_MAX-1LL)
> #define LLONG_MIN (-LLONG_MAX-1LL)
> #endif
>
>
> COMPLETE MAKE SUCCESSFUL using Borland 5.0 IDE with the above changes.
> A) LL changed to L
> B) the '#' removed from the -DHAVE_PNG_H
I'll have to check my BC++ scripts now. So far they've always seemed to work, so I
don't know why you're seeing problems with it...
- 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
