Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)

[suzuki toshiya]

Dear Erik,

Of course, I want to receive the patch to improve (rather,
I should call restore) PIC build. I wish if my overhaul
have not made you troubled.

Erik Dahlstrom wrote:
> diff --git a/modules/libfreetype/include/freetype/internal/ftdriver.h 
> b/modules/libfreetype/include/freetype/internal/ftdriver.h
> index bbb9ddd..333f908 100644
> --- a/modules/libfreetype/include/freetype/internal/ftdriver.h
> +++ b/modules/libfreetype/include/freetype/internal/ftdriver.h
> @@ -366,11 +366,11 @@ FT_BEGIN_HEADER
>    FT_Create_Class_##class_( FT_Library        
> library,                       \
>                              FT_Module_Class**  output_class 
> )                \
>    
> {                                                                          
> \
> -    FT_Driver_Class  
> clazz;                                                  \
> +    FT_Driver_Class  clazz = 
> NULL;                                           \
>      FT_Error         
> error;                                                  \
>      FT_Memory        memory = 
> library->memory;                               \
>                                                                               
> \
> -    if ( FT_ALLOC( clazz, sizeof(*clazz) ) 
> )                                 \
> +    if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) 
> )                     \
>        return 
> error;                                                          \
>                                                                               
> \
>      error = class_##_pic_init( library 
> );                                    \
> 
> 
> If you prefer I can send another patch with those changes.

Ahhh... although I'm not sure whether ANSI C requests that
sizeof(*xxx_p) works as sizeof(xxx), I think such modification
is not bad idea. BTW, sizeof(*xxx_p) style coding is refused
by the compiler? or linker?

> Regarding testing of the PIC mode, yes you can test it on Linux even 
> though PIC isn't normally required there. The linker that has issues 
> with strings and array initializations like in ftobjs.c is for the Brew 
> platform.

Thanks. I heard that BREW's official SDK is based on ARM RVCT
compiler in Microsoft Visual C++ IDE. I don't have MSVC IDE,
but I will check if there is any free-charged version of RVCT
compiler.

Regards,
mpsuzuki

> 
> On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya 
> <address@hidden> wrote:
> 
>> During the overhaul for PIC build, I found that cache subsystem
>> of FreeType2 is not ready for PIC build, thus the demo programs
>> doing rasterization (e.g. ftview, ftbench) cannot be built.
>> Thus I can check if the code is compilable, but cannot check
>> if the code is working. Maybe most expected direction is the
>> porting of the cache subsystem for PIC build (even if there is
>> no real user of it on embedded system), but extending some demo
>> programs for FreeType2 without cache subsystem would be easier
>> first step.
>>
>> # I assume FreeType2 built in PIC mode will work in the operating
>> # system that PIC mode is NOT required (e.g. Linux). If it's
>> # misunderstanding, please let me know.
>>
>> Any comments?
>>
>> Regards,
>> mpsuzuki
>>
>> suzuki toshiya wrote:
>>> Dear Erik,
>>>
>>> I have made some overhaul for PIC build, and, your patch to
>>> modify resource fork support for PIC build is applied with
>>> some coding style changing. Please check whether GIT head
>>> works on your platform.
>>>
>>> BTW,
>>>
>>> diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
>>> index 1a5a327..fc687f5 100644
>>> --- a/src/base/ftobjs.c
>>> +++ b/src/base/ftobjs.c
>>> @@ -4533,7 +4533,9 @@
>>>       */
>>>      {
>>>        FT_UInt      m, n;
>>> -      const char*  driver_name[] = { "type42", NULL };
>>> +      const char*  driver_name[2];
>>> +         driver_name[0] = "type42";
>>> +         driver_name[1] = NULL;
>>>
>>>
>>>        for ( m = 0;
>>>
>>> is not committed yet, because I want to know which linker complains
>>> about such initialization. If possible, please let me know 1 example
>>> to be documented in ChangeLog. I'm not saying "there should not be
>>> such linker", just I want to know 1 example, for good documentation.
>>> Sorry for troubling you.
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>> suzuki toshiya wrote:
>>>> Dear Erik,
>>>>
>>>> Sorry for your trouble and thank you for providing a patch,
>>>> I will check it in this weekend. Please give me a few days.
>>>>
>>>> Regards,
>>>> mpsuzuki
>>>>
>>>> Werner LEMBERG wrote:
>>>>>> The commits in question are both dealing with compilation of
>>>>>> 'complex' structures and static globals.
>>>>> Thanks for the patch.  Toshiya-san, can you have a look and take care
>>>>> of it, please?
>>>>>
>>>>>
>>>>>     Werner
> 
>