Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Another possibility is that the ARM specific multiplication routines are buggy... I did also try compiling with assembler turned off -- I don't remember the preprocessor switch, but I did find it somewhere. It did not change the results. Todd ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
Thank you very much for your attention to this. The ARM stuff is on an embedded system, so I'll have to first figure out (a) how to cross-compile the things you requested (make devel; make) (b) how to support printf within freetype library I have been building it by adding the files to the ARM IDE I'm using, so whether the configure log is useful is dubious -- I sent that directly in a separate email. Since I have something somewhat working (if not optimally), I may have to go with that for now until I have time to get back to figuring out freetype. Todd -Original Message- From: Werner LEMBERG [mailto:w...@gnu.org] Sent: Monday, April 18, 2011 5:50 AM To: t...@spraguetech.com Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4) My question is: where should I look and/or what should I change, to make them act the same? The FT_INT64 stuff is only used in a single file, `src/base/ftcalc.c'. However, AFAIK, the GNU C compiler always defines a 64bit data type (`long long int'), so I'm really surprised that you experience this problem. Perhaps this is different for GNU C on ARM? Can you try make devel make (from a fresh tarball) for compiling FreeType so that you bypass the `configure' script? Do you then get correct results for your demo application? Can you please also post the file `builds/unix/config.log' (compressed)? In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
My question is: where should I look and/or what should I change, to make them act the same? The FT_INT64 stuff is only used in a single file, `src/base/ftcalc.c'. However, AFAIK, the GNU C compiler always defines a 64bit data type (`long long int'), so I'm really surprised that you experience this problem. Perhaps this is different for GNU C on ARM? Can you try make devel make (from a fresh tarball) for compiling FreeType so that you bypass the `configure' script? Do you then get correct results for your demo application? Can you please also post the file `builds/unix/config.log' (compressed)? In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Math error? Spacing drastically different VS2005 to GNU/ARM (v2.4.4)
In particular, it appears to me that the ARM system is doing some incorrect math from the metrics width value of 0x2C0 to get 0x800, but I'm having trouble identifying why this might be. Finally, can you decorate the various functions of ftcalc.c with some printf calls to find out where the difference comes from? Up to now, we've never received a similar problem report. Another possibility is that the ARM specific multiplication routines are buggy... I've just updated `builds/unix/ftconfig.in' with the additional assembler routines from `include/freetype/config/ftconfig.h', but this shouldn't make a difference for you, I believe. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
