Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sirs, Thank you for correcting my misunderstanding. On Sat, 24 Mar 2007 16:39:43 +0800 Jjgod Jiang [EMAIL PROTECTED] wrote: 2007/3/23, [EMAIL PROTECTED] [EMAIL PROTECTED]: Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Yes, I can confirm that, Intel Core 2 Duo (now all upgraded MacBook Pro, MacBook and iMac using) is 64-bit CPU. Xcode Tools support generating x86_64 binaries since version 2.4. On Fri, 23 Mar 2007 15:23:37 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 3/24/07 1:48 AM, [EMAIL PROTECTED] said: it is possible that ppc64 Carbon is still missing in future. No. Apple has already said that 64 bit Carbon will be for both Intel and PPC. See: http://www.apple.com/macosx/leopard/64bit.html Just I've updated ftconfig.in and ftconfig.h (for some building system without running configure) as following: #if ( defined( __APPLE__ ) !defined( DARWIN_NO_CARBON ) ) || \ ( defined( __MWERKS__ ) defined( macintosh )) /* no Carbon frameworks for 64bit 10.4.x */ #include AvailabilityMacros.h #if defined( __LP64__ ) \ ( MAC_OS_X_VERSION_MIN_REQUIRED = MAC_OS_X_VERSION_10_4 ) #define DARWIN_NO_CARBON 1 #else #define FT_MACINTOSH 1 #endif #endif However, I'm not sure whether 10.5.x will set default MAC_OS_X_VERSION_MIN_REQUIRED to 10.5 (system including Carbon) or 10.4 (Carbon-free system). Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On 3/26/07 4:47 PM, [EMAIL PROTECTED] said: Just I've updated ftconfig.in and ftconfig.h (for some building system without running configure) as following: #if ( defined( __APPLE__ ) !defined( DARWIN_NO_CARBON ) ) || \ ( defined( __MWERKS__ ) defined( macintosh )) /* no Carbon frameworks for 64bit 10.4.x */ #include AvailabilityMacros.h #if defined( __LP64__ ) \ ( MAC_OS_X_VERSION_MIN_REQUIRED = MAC_OS_X_VERSION_10_4 ) MAC_OS_X_VERSION_10_4 is not always defined (for example on 10.2 systems), but it is probably always defined if __LP64__ is defined. Still, this would be safer: #if defined( __LP64__ ) \ ( MAC_OS_X_VERSION_MIN_REQUIRED = 1040 ) or #if defined( __LP64__ ) \ defined( MAC_OS_X_VERSION_10_4 ) \ (MAC_OS_X_VERSION_MIN_REQUIRED = MAC_OS_X_VERSION_10_4) ) #define DARWIN_NO_CARBON 1 #else #define FT_MACINTOSH 1 #endif #endif However, I'm not sure whether 10.5.x will set default MAC_OS_X_VERSION_MIN_REQUIRED to 10.5 (system including Carbon) or 10.4 (Carbon-free system). Alas, I cannot discuss 10.5. But I'll just say the above checks look good to me. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Hi, 2007/3/23, [EMAIL PROTECTED] [EMAIL PROTECTED]: Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Yes, I can confirm that, Intel Core 2 Duo (now all upgraded MacBook Pro, MacBook and iMac using) is 64-bit CPU. Xcode Tools support generating x86_64 binaries since version 2.4. - jjgod. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On 3/23/07 7:04 AM, [EMAIL PROTECTED] said: I see. Yet I've not checked 10.4.9, can it run 64bit Intel Mac executables? I think Mac OS X upto 10.4.8 cannot execute 64bit Intel Mac executables. In the other word, the case we have to exclude is building 64bit Intel Mac binary ON 10.4.9, not building 64bit Intel Mac binary FOR 10.4.9 ? 64 bit support is the same for both Intel and PPC. 64 bit support is the same from 10.4.0 to 10.4.9. 64 bit support is the same wether you are 'building on' or 'building for'. On 10.4.x (on either PPC or Intel) you _can_ create 64 bit executables. But they can _only_ link against System.framework and Accelerate.framework. A 64 bit executable cannot link against Carbon.framework, because Carbon.framework is only 32 bit. So, freetype can be built as 64 bit if ftmac.c is excluded. ftmac.c cannot be built as 64 bit because it uses Carbon.framework. On 10.5 this restriction is gone, but other changes will be needed for 10.5, so I don't think we should worry yet. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Sean McBride wrote: On 3/23/07 7:04 AM, [EMAIL PROTECTED] said: I see. Yet I've not checked 10.4.9, can it run 64bit Intel Mac executables? I think Mac OS X upto 10.4.8 cannot execute 64bit Intel Mac executables. In the other word, the case we have to exclude is building 64bit Intel Mac binary ON 10.4.9, not building 64bit Intel Mac binary FOR 10.4.9 ? 64 bit support is the same for both Intel and PPC. 64 bit support is the same from 10.4.0 to 10.4.9. 64 bit support is the same wether you are 'building on' or 'building for'. Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Sean McBride wrote: On 3/24/07 12:02 AM, [EMAIL PROTECTED] said: I see. Yet I've not checked 10.4.9, can it run 64bit Intel Mac executables? I think Mac OS X upto 10.4.8 cannot execute 64bit Intel Mac executables. In the other word, the case we have to exclude is building 64bit Intel Mac binary ON 10.4.9, not building 64bit Intel Mac binary FOR 10.4.9 ? 64 bit support is the same for both Intel and PPC. 64 bit support is the same from 10.4.0 to 10.4.9. 64 bit support is the same wether you are 'building on' or 'building for'. Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Yes. (Of course, it must be a 64-bit CPU, not all Intel Macs have 64 bit CPUs. The Mac Pro is 64 bit, the Mac Mini is 32 bit.) Maybe this will be helpful: http://www.apple.com/jp/macosx/features/64bit/ Thank you, yet I don't have access to Mac Pro. 64bit-x86 Carbon will be provided in future, and it is possible that ppc64 Carbon is still missing in future. Thus, unified conditional __LP64__ for current status may be disunified in future, aslike #if defined( __ppc64__ ) || \ ( defined( __x86_64__ ) MAC_OS_X_VERSION_MIN_REQUIRED 1050 ) I will rewrite the conditional without unification by __LP64__. Please wait a few days (now I'm in duty-trip without Macintosh). However, I remember configure checks Carbon framework availability, so I wish building FreeType2 on 64bit Intel Mac 10.4.x won't cause such problem. You had problem? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On 3/24/07 1:48 AM, [EMAIL PROTECTED] said: 64bit-x86 Carbon will be provided in future Yes. it is possible that ppc64 Carbon is still missing in future. No. Apple has already said that 64 bit Carbon will be for both Intel and PPC. See: http://www.apple.com/macosx/leopard/64bit.html Thus, unified conditional __LP64__ for current status may be disunified in future, aslike #if defined( __ppc64__ ) || \ ( defined( __x86_64__ ) MAC_OS_X_VERSION_MIN_REQUIRED 1050 ) I will rewrite the conditional without unification by __LP64__. Please wait a few days (now I'm in duty-trip without Macintosh). However, I remember configure checks Carbon framework availability, so I wish building FreeType2 on 64bit Intel Mac 10.4.x won't cause such problem. You had problem? VTK does not use freetype's configure system, instead VTK uses CMake. I did not try to build freetype as x86_64 on 10.4. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On Thu, 22 Mar 2007 11:43:58 +0900, Miles Bader [EMAIL PROTECTED] said: David Turner [EMAIL PROTECTED] writes: this will generate an error with certain compilers/pre-processors if __LP64__ is not defined. generally speaking #if X is not a portable statement, except if you ensure that the macro is always defined beforehand. Is this true according to the C standard, or a problem with any non-obsolete compilers? This is one of these things that are certainly not clarified in the C standard [1], which specifies that #if shall be followed by any constant-expression, the latter being defined very loosely in the C language description, and specific constraints not really detailed. So #if FOO, where FOO is undefined is ok with GNU cpp [2] but not with Visual C++ [3] I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... [I ask because such usage is widespread, and although gcc has a warning for it, it doesn't get turned on even with -ansi -pedantic -Wall -Wextra, you have to enable it explicitly.] I have no idea why, I suppose that forcing -Wundef with -ansi -pedantic would have created problems when compiling a lot of code, due to its widespread usage in Unix sources. Hope this helps, - David [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf [2] http://gcc.gnu.org/onlinedocs/cpp/If.html#If [3] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vcrefPreprocessorReference.asp ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
The relevant part is where it says how to handle incorrect expression syntax in an #if statement. Because where FOO is undefined, #if FOO expands to a null expression which is not a valid one... I have not found anything in the document that discusses this case; maybe I missed it, but it's strange that the MSDN documentation doesn't mention it on the other hand, I just tried to compiled the following program on Windows: #if FOO_IS_UNDEFINED #error should not happen #else int dummy; #endif I had correct compilation, without warnings with all the following compilers though: MingW (GCC) Visual C++ 6 Visual C++ 7 Borland C++ 5.5 OpenWatcom C++ (don't remember version) Win32-LCC (don't remember version) I only used the default compiler options though (no -ansi or equivalent); I would say it's pretty widely supported. Apparently the Microsoft compilers and their documentation don't agree on everything; I'm not too surprised, I've seen the same thing with GCC :-) Regards, - David So #if FOO, where FOO is undefined is ok with GNU cpp [2] but not with Visual C++ [3] I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... Well, a trick I have used in one of my projects is to write #if FOO+0 but most people don't like it. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On 3/22/07 10:17 AM, [EMAIL PROTECTED] said: Now I'm going to commit your patch to CVS head, but I have small question. Your patch to builds/unix/ftconfig.in will disable Carbon support on 64bit ABI in Intel Mac. It means that the resource-fork based font support (ftmac.c) are unavailable completely. Not only deprecated QuickDraw and FileManager (FSSpec etc) functions, but also ATS and FSRef functions. It is intended design? Yes. On the current Mac OS (10.4.9 and earlier), on both PPC and Intel, none of QuickDraw, File Manager, ATS, FSRefs, FSSpecs, etc. are available to 64 bit applications. Basically, ftmac.c cannot work in 64 bit on 10.4. On 10.5, ftmac.c will be able to work in 64 bit, but since 10.5 is unreleased -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Quoting David Turner [EMAIL PROTECTED]: I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... KR C allowed that syntax. I had thought it was standard C too. I'd say that Visual C isn't following the conventions and that this almost qualifies as a bug in it. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
David Turner [EMAIL PROTECTED] writes: I had correct compilation, without warnings with all the following compilers though: MingW (GCC) Visual C++ 6 Visual C++ 7 Borland C++ 5.5 OpenWatcom C++ (don't remember version) Win32-LCC (don't remember version) I also tried several proprietary compilers at work (including one using the EDG frontend, well known for being highly standard compliant), with the same results -- correct compilation, no warning. I used the most strict warning mode/option I could find with all of them. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
I have been working on updating VTK (www.vtk.org) from freetype 2.1.9 to the 2.3.2. It has gone pretty smoothly, thanks in part to the detailed changelogs you guys keep, thank you! I invest a considerable amount of time to maintain them... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Now I'm going to commit your patch to CVS head, but I have small question. Your patch to builds/unix/ftconfig.in will disable Carbon support on 64bit ABI in Intel Mac. It means that the resource-fork based font support (ftmac.c) are unavailable completely. Not only deprecated QuickDraw and FileManager (FSSpec etc) functions, but also ATS and FSRef functions. It is intended design? Regards, mpsuzuki On Tue, 20 Mar 2007 11:24:49 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 3/20/07 9:56 AM, [EMAIL PROTECTED] said: 1) builds/unix/ftconfig.in - minor Mac fix, test against __LP64__ not __ppc64__. There are also 64 bit Intel CPUs. Thank you for notice 64bit API in Intel Mac, yet I don't have that. #if __LP64__ ... #endif might be simpler, how do you think? As David said, I do this to prevent a warning from gcc's -wundef. Apple is inconsistent in their own headers. Sometimes they do #if __LP64__ sometimes they do #ifdef __LP64__. I suspect __LP64__ is either not defined at all, or defined to 1. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
David Turner [EMAIL PROTECTED] writes: this will generate an error with certain compilers/pre-processors if __LP64__ is not defined. generally speaking #if X is not a portable statement, except if you ensure that the macro is always defined beforehand. Is this true according to the C standard, or a problem with any non-obsolete compilers? [I ask because such usage is widespread, and although gcc has a warning for it, it doesn't get turned on even with -ansi -pedantic -Wall -Wextra, you have to enable it explicitly.] -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
