Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk

[Sean McBride]

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

[mpsuzuki]

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:



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

[Jjgod Jiang]

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

[Sean McBride]

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:


>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

[mpsuzuki]

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: 



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

[Sean McBride]

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: 

--

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

[mpsuzuki]

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

[Sean McBride]

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

[Miles Bader]

"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

[mpsuzuki]

Dear Sir,

Yesterday I've commited 2 fixes of 3 you proposed, thank you.

On Thu, 22 Mar 2007 10:03:40 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:
> On 3/22/07 10:17 AM, [EMAIL PROTECTED] said:
> >Your patch to builds/unix/ftconfig.in will disable
> >Carbon support on 64bit ABI in Intel Mac.

> >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.

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" ?

I've ever checked developer tools for 10.4.8 ppc, which was
told as "ready to cross build for 64bit Intel Mac",
but I felt it was unfinished works because various libraries
were missing (as you told) for 64bit Intel Mac and I thought
most people would not use it for real migration. If people are
using such kit for real migration, I have to add exclusion.

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

[gww]

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...
K&R 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

[Sean McBride]

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

[David Turner]

> 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

[Behdad Esfahbod]

On Thu, 2007-03-22 at 04:35 -0400, David Turner wrote:
> 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.

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...

> 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

[David Turner]

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

[Miles Bader]

"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

Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk

[mpsuzuki]

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

[Werner LEMBERG]

> 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

[Sean McBride]

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.

>> 2) builds/unix/ftsystem.c
>>  - fix compiler warning about 64 to 32 bit conversion.  Also make sure
>> file is not so big that the cast to 32 bit will lose data.  A better fix
>> would be to make 'stat_buf.st_size' a ssize_t, I didn't try that because
>> it may have wider implications.  But this patch is better than nothing.
>
>As you write, the issue caused by ssize_t (of st_size)
>vs unsigned long (of FT_Stream->size) should be checked
>in detail, please wait. However, your quick looks good
>as temporal solution.

I agree fully.  My solution is temporary, I don't know enough about
freetype to attempt changing an internal data structure. :)

I'm glad you guys are happy with the changes.  I look forward to seeing
them in CVS.  It will be nice to have a VTK with no local changes to freetype!

--

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

[David Turner]

Hello,

> #if __LP64__
> ...
> #endif
> 
> might be simpler, how do you think?
> 

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.

> > 3) include/freetype/config/ftstdlib.h
> >  - fix compiler warning
> 
> I think include/freetype/config/ftconfig.in is
> the right place of compiler-specific configuration.

I agree, and will commit the proper fix

thanks to all,

- David


___
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

[mpsuzuki]

Dear Sir,

On Mon, 19 Mar 2007 17:49:08 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:
> There are a few changes the VTK people and I made and I am submitting a
> patch to this email for your consideration.  The patch is against today's CVS.

Thank you for writing patch for Intel Mac
in 64bit ABIs.

> 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?

> 2) builds/unix/ftsystem.c
>  - fix compiler warning about 64 to 32 bit conversion.  Also make sure
> file is not so big that the cast to 32 bit will lose data.  A better fix
> would be to make 'stat_buf.st_size' a ssize_t, I didn't try that because
> it may have wider implications.  But this patch is better than nothing.

As you write, the issue caused by ssize_t (of st_size)
vs unsigned long (of FT_Stream->size) should be checked
in detail, please wait. However, your quick looks good
as temporal solution.

> 3) include/freetype/config/ftstdlib.h
>  - fix compiler warning

I think include/freetype/config/ftconfig.in is
the right place of compiler-specific configuration.
Unfortunately, my SGI IRIXs don't have official
MIPS C compilers (so I cannot reproduce the issue),
could you transplant the hook to ftconfig.in?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk

[Sean McBride]

Hi all,

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!

There are a few changes the VTK people and I made and I am submitting a
patch to this email for your consideration.  The patch is against today's CVS.

1) builds/unix/ftconfig.in
 - minor Mac fix, test against __LP64__ not __ppc64__.  There are also
64 bit Intel CPUs.

2) builds/unix/ftsystem.c
 - fix compiler warning about 64 to 32 bit conversion.  Also make sure
file is not so big that the cast to 32 bit will lose data.  A better fix
would be to make 'stat_buf.st_size' a ssize_t, I didn't try that because
it may have wider implications.  But this patch is better than nothing.

3) include/freetype/config/ftstdlib.h
 - fix compiler warning

It would be great if these could be added to 2.3.3.

Thanks,

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada
Index: builds/unix/ftconfig.in
===
RCS file: /sources/freetype/freetype2/builds/unix/ftconfig.in,v
retrieving revision 1.19
diff -r1.19 ftconfig.in
103c103
< #if defined( __ppc64__ ) /* no Carbon for ppc64 */
---
> #if defined( __LP64__ ) && ( __LP64__ != 0 ) /* no Carbon in 64bit on 10.4 */
Index: builds/unix/ftsystem.c
===
RCS file: /sources/freetype/freetype2/builds/unix/ftsystem.c,v
retrieving revision 1.33
diff -r1.33 ftsystem.c
269c269,280
< stream->size = stat_buf.st_size;
---
>   /* stat_buf.st_size and stream->size are not the same  */
>   /* type.  On some platforms, the former is 64 bit and  */
>   /* the latter is 32 bit.  So do a test.*/
>   /* Ideally, stream->size should be ssize_t also.   */
> if ( stat_buf.st_size > ULONG_MAX )
> {
>   FT_ERROR(( "FT_Stream_Open: file is too big" ));
>   goto Fail_Map;
> }
> 
> /* This cast potentially truncates a 64 bit to 32 bit! */
> stream->size = (unsigned long)stat_buf.st_size;
318c329
<   } while ( (unsigned long)total_read_count != stream->size );
---
>   } while ( total_read_count != (ssize_t)stream->size );
Index: include/freetype/config/ftstdlib.h
===
RCS file: /sources/freetype/freetype2/include/freetype/config/ftstdlib.h,v
retrieving revision 1.18
diff -r1.18 ftstdlib.h
169a170,175
>   /* Fix compiler warning with sgi compiler */
> #if defined(__sgi) && !defined(__GNUC__)
> #  if   (_COMPILER_VERSION >= 730)
> #  pragma set woff 3505
> #  endif
> #endif
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel