Re: [ft-devel] a couple of warnings from 2.5.4 with mingw/darwinx

[Hin-Tak Leung]

Actually that's what I have. Sorry about the delay. My build was driven
by the crosscompile framework. 

http://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Running_the_..2Fconfigure_script

It is a bit complicated, but I think in a nutshell it means running
configure with CC="darwinx-gcc -arch ppc -arch i386 -arch x86_64"
i.e. building "fat" object files which are triarch.

for your reference, here is the freetype headers shipped by xquartz.
I have also what apple did with freetype (they shipped it "officially" for 
10.6/10.7,
I think the xquartz people are essentially also apple's) e.g.
https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.7.sdk/usr/X11/include/freetype2/freetype/config/ftconfig.h

xquartz's freetype headers seems to have extra assembly codes;
whereas the apple SDKs' freetype headers seems to have FT_MACINTOSH always
enabled. Am I correct?

--------------------------------------------
On Thu, 29/1/15, suzuki toshiya <address@hidden> wrote:
 
 I tried with Fedora's
 cross compiler (for darwinx),
 and could not
 reproduce the error. Which toolchain
 I
 should try in next?
 
 Regards,
 mpsuzuki
 
 suzuki toshiya wrote:
 > Hi,
 > 
 > Yet I could not reproduce the problem on
 my Mac OS X,
 > I think I should try on
 the cross building system.
 > However,
 I'm unfamiliar with the defacto standard of
 > the cross compiler for DarwinX on other
 platform.
 > 
 >
 Considering that you also mentioned "for mingw", I
 guess
 > you're working on some unix
 like platform. Your cross
 > compiler for
 DarwinX is built by yourself? Or you
 >
 installed some prebuilt packages? The prebuilt package
 > I could find was only for Fedora:
 > http://build1.vanpienbroek.nl/fedora-cross-darwinx/fedora-cross-darwinx.repo
 > 
 > Please let me know
 more detail about your platform working for DarwinX.
 > 
 > Regards,
 > mpsuzuki
 > Hin-Tak
 Leung wrote:
 >> I have got to the
 bottom of the latter issue; I mentioned that I was
 cross-compiling,
 >> for apple, right?
 It really needs the --enable-biarch-config switch:
 >>
 >> without
 --enable-biarch-config:
 >>
 >> checking size of long... 8
 >> checking whether cpp computation of
 bit length in ftconfig.in works... no
 >>
 >> with
 --enable-biarch-config:
 >>
 >> checking size of long... 8
 >> checking whether cpp computation of
 bit length in ftconfig.in works... broken but use it
 >>
 >> I don't
 know where it gets the size of long from. The apple
 compiler
 >> front end is quite
 interesting in that it drives the individual
 architectures
 >> and put all three (or
 4) outputs from 32-bit powerpc, 32-bit intel, 64-bit intel
 into 1 "object" files.
 >>
 And the warnings come from the "under the hood"
 compile of the 32-bit outputs.
 >>
 >> The 32-bit powerpc and 32-bit intel
 arch have size of long = 4. If I use
 >> the individual single architecture
 front end, then it shows "4" and "yes"
 respectively.
 >>
 >> I am wondering whether
 --enable-biarch-config should be better documented,
 >> and/or made the default for Mac OS X?
 (though it probably make less sense now since
 >> apple has moved to 64-bit intel
 somewhat exclusively lately)
 >>
 >> Also, can it not use stdint.h and
 int64_t directly? "long" is rather vague :-).
 >>
 >>
 --------------------------------------------
 >> On Sat, 17/1/15, Werner LEMBERG <address@hidden> wrote:
 >>  
 >>  Hello
 >>  Hin-Tak!
 >> 
 
 >>  
 >> 
 >
 >> 
 /usr/i686-w64-mingw32/sys-root/mingw/include/harfbuzz/hb-common.h:309:26:
 >>  > warning: ISO C restricts
 enumerator values
 >>  to range of
 'int'
 >>  >
 >>  [-Wpedantic]
 >>  >   
 >>  _HB_SCRIPT_MAX_VALUE    =
 HB_TAG_MAX, /*< skip
 >>  >*/
 >>  >                 
    
 >>   
    ^
 >>  
 >>  This is
 >>  a
 known but harmless issue, and work-arounds seem to be
 >>  very
 >> 
 inelegant, IIRC.
 >>  
 >>  >
 >> 
 /root/rpmbuild/BUILD/freetype-2.5.4/src/base/fttrigon.c:74:
 >>  warning:
 >> 
 > right shift count >= width
 >>  of type
 >> 
 
 >>  This looks
 >>  strange.  Here's the
 corresponding code line:
 >>  
 >>    val = (FT_Fixed)( (
 >>  (FT_Int64)val * FT_TRIG_SCALE +
 0x40000000UL ) >> 32
 >>  );
 >>  
 >>  We
 explicitly convert to
 >>  a 64bit
 entity (`FT_Int64'), and this should
 >>  allow a shifting by 32 bits...  So
 the basic
 >>  question is whether
 >>  `FT_Int64' is
 >>  *indeed* a 64bit type.
 >>  
 >>  
 >>      Werner
 >>  
 >>
 >>
 _______________________________________________
 >> Freetype-devel mailing list
 >> address@hidden
 >> https://lists.nongnu.org/mailman/listinfo/freetype-devel
 >
 
 > 
 >
 _______________________________________________
 > Freetype-devel mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/freetype-devel

xquartz-freetype-includes.tgz
Description: application/compressed-tar