kc3-lang/freetype/src/pshinter/module.mk
-
Show log
Commit
-
Hash : ce33a312
Author :
Date : 2008-12-21T10:29:30
FT_USE_MODULE declares things as: extern const FT_Module_Class (or similar for C++). However, the actual types of the variables being declared are often different, e.g., FT_Driver_ClassRec or FT_Renderer_Class. (Some are, indeed, FT_Module_Class.) This works with most C compilers (since those structs begin with an FT_Module_Class struct), but technically it's undefined behavior. To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7 paragraph 2: All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined. (And they are not compatible types.) Most C compilers don't reject (or even detect!) code which has this issue, but the GCC LTO development branch compiler does. (It outputs the types of the objects while generating .o files, along with a bunch of other information, then compares them when doing the final link-time code generation pass.) Patch from Savannah bug #25133. * src/base/ftinit.c (FT_USE_MODULE): Include variable type. * builds/amiga/include/freetype/config/ftmodule.h, include/freetype/config/ftmodule.h, */module.mk: Updated to declare pass correct types to FT_USE_MODULE.
-
src/pshinter/module.mk
-
# # FreeType 2 PSHinter module definition # # Copyright 1996-2001, 2006 by # David Turner, Robert Wilhelm, and Werner Lemberg. # # This file is part of the FreeType project, and may only be used, modified, # and distributed under the terms of the FreeType project license, # LICENSE.TXT. By continuing to use, modify, or distribute this file you # indicate that you have read the license and understand and accept it # fully. FTMODULE_H_COMMANDS += PSHINTER_MODULE define PSHINTER_MODULE $(OPEN_DRIVER) FT_Module_Class, pshinter_module_class $(CLOSE_DRIVER) $(ECHO_DRIVER)pshinter $(ECHO_DRIVER_DESC)Postscript hinter module$(ECHO_DRIVER_DONE) endef # EOF