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 <[email protected]> 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 >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/freetype-devel > > > _______________________________________________ > Freetype-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/freetype-devel _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
