CVSROOT:/sources/freetype
Module name:freetype2
Changes by: suzuki toshiya mpsuzuki 07/12/06 10:27:15
Modified files:
. : ChangeLog
include/freetype/internal: ftrfork.h
src/base : ftrfork.c
Log message:
*
CVSROOT:/cvsroot/freetype
Module name:freetype2
Changes by: Werner LEMBERG wl 07/12/06 17:17:30
Modified files:
. : ChangeLog configure
builds/unix: detect.mk
src/cff: cffgload.c
src/truetype : ttgload.c
Log
Anybody have any ideas on the use of volatile
joolz
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
[EMAIL PROTECTED] (JULIAN GARDNER) wrote:
I did a grep and found volatiles used in numerous places, can someone
please explain why they are being used, as i understand and have used in
the past . years freetype should not need volatiles, there are no
interrupt calls and no way in which
I have hit the same problem with 2.3.5:
ttgload.c(1406) : error C2037: left of 'GS' specifies undefined
struct/union 'TT_ExecContextRec_'
ttgload.c(1418) : error C2037: left of 'GS' specifies undefined
struct/union 'TT_ExecContextRec_'
It seems to occur when *all* bytecode interpretation
I did a grep and found volatiles used in numerous places, can
someone please explain why they are being used, as i understand and
have used in the past . years freetype should not need
volatiles, there are no interrupt calls and no way in which data
should be changed without a call into
IIRC using setjmp() and longjmp() with some versions of gcc requires
declaring some variables as volatile or it may clobber them.
In case we really still need volatiles it might be an idea to define a
macro VOLATILE in the config headers and use this instead...
Werner
Pass options from one configure script to another AS IS (not
expanded). That needed for options like
--includedir='${prefix}/include'. Patch follows: [...]
Applied to the CVS, thanks.
Werner
___
Freetype-devel mailing list
