RE: [Devel] compiling freetype on 16-bit embedded

[Steve Calzone]

David,
Much thanks for your reply and tips.  I am using the /G1 switch which
supposedly identifies the processor as a 186 for the compiler, but the
__MSC_VER macro is still defined.  In my case, #undef
FT_CONFIG_OPTION_FORCE_INT64 does not force the removal of support for
64-bit types as I assumed.  I was hoping you could provide an override that
didn't force me to use __STDC__...

If you keep the enums unique within the lo-order 16-bits the warnings will
not hurt (exhale:o)

Thanks again,
Steve


-----Original Message-----
From: address@hidden [mailto:address@hidden
Behalf Of David Turner
Sent: Friday, March 08, 2002 7:33 AM
To: address@hidden
Subject: Re: [Devel] compiling freetype on 16-bit embedded


Hello,

Steve Calzone a écrit :
>
> Hi y'all,
> trying to compile for 16-bit embedded system, found similar problems to
the
> C++ issues, except my enums are 16-bits.  This is ok as long as the
lo-order
> 16-bits of all enums are unique.
> Also, could not compile at all unless __STDC__ defined to remove all
> references to 64-bit types (since I don't seem to have a 64-bit type).
>
> I am using the Microsoft (R) C/C++ Optimizing Compiler Version 8.00c.  For
> now, I must use this compiler version.  The code is compiled for the Am186
> processor.
>
> Attached are some of my changes to successfully compile.
>
I've looked at your changes, and I'm not going to incorporate them within
the FreeType sources. It seems that you didn't understand the configuration
process very well. Here are a few tips:

  - you don't need 64-bit types to compile and run FreeType. Their use
    is purely optional, and will actually sometimes result in slightly
    slower code depending on your compiler/platform !!

    our current "ftconfig.h" test for the __MSC_VER macro to detect the
    Visual C++ compiler. If it is found, it automatically uses 64-bit ints
    since these are supposed to be available..

    if your own compiler defines this macro too, do you know of any pragma
    or compiler-specific macro that could be used to detect that 64-bits
    aren't available (for example, we could test that the target CPU isn't
    x86 and that should be enough..)


  - the "__cdecl" keyword is not ANSI C, you should instead define your
    own FT_CALLBACK_DEF before including <ft2build.h>
    as in:

      #ifdef __cplusplus
      #  define  FT_CALLBACK_DEF(x)  extern "C" x
      #else
      # define  FT_CALLBACK_DEF(x)   static x  __cdecl
      #endif

      #include <ft2build.h>

    this kind of definitions is compiler-specific so there is very little
    need to include it within the sources unless you've got a
    straightforward way to detect the compiler at compilation time..


> The warnings I still receive from the compiler:
>
> ftbase.c
> ftobjs.c(2271) : warning C4078: case constant '1651078259' too big for the
> type of the switch expression
> ftobjs.c(73) : warning C4761: integral size mismatch in argument;
conversion
> supplied
> ftobjs.c(115) : warning C4761: integral size mismatch in argument;
> conversion supplied
> ftobjs.c(1135) : warning C4761: integral size mismatch in argument;
> conversion supplied
> ftstream.c(140) : warning C4761: integral size mismatch in argument;
> conversion supplied
>
> ftglyph.c
> ftglyph.c(135) : warning C4761: integral size mismatch in argument;
> conversion supplied
> ftglyph.c(618) : warning C4761: integral size mismatch in argument;
> conversion supplied
>
> sfnt.c
> ttsbit.c(996) : warning C4761: integral size mismatch in argument;
> conversion supplied
>
> Please advise how to get rid of these warnings, if possible.
>
I'll try to have a look. Don't hold your breath though, I'm much too busy
right now to do that..

Regards,

- David Turner

_______________________________________________
Devel mailing list
address@hidden
http://www.freetype.org/mailman/listinfo/devel