Re: [ft-devel] Position Independent Port of FreeType2

[Mickey Gabel]

This post just details my reasoning and the constraints I have to work 
with, it contains little technical information (unless you really care 
about BREW). It came out a bit of a rant...

Werner LEMBERG wrote:
> > What I am talking about is that global/static data must be const,
> > and ALSO cannot contain ANY pointers, because those require
> > relocations.
>
> Hmm.
>
> > [...] This is a global struct, which although const, contains many
> > pointer, that require relocations. This is impossible on BREW (and
> > other systems were the code must be position independent).
>
> This is definitely a wrong statement.  As has been noted in another
> email, gcc CAN generate position independent code just fine using the
> current source code of FreeType,

Agreed, in that there's a hack that allows applications to do this.
BREW's load/linker simply doesn't do the relocations, but if you are 
building a full application, you can use GCC with a hack that at program 
startup performs the relocation. Basically does the OS's job at 
application startup.
This is impossible for me, unfortunately. See below.

> and up to now we have had never
> complaints w.r.t. PIC, and FreeType is used in a lot of embedded
> systems, as far as we know.  Apparently, the BREW compiler isn't
> sophisticated enough to handle such issues automatically.  But maybe
> there are some additional issues I'm missing.

This is all true for GCC, but apparently not for the earlier versions of 
RVCT and almost definitely not for ADS (which is very old). I'll discuss 
why I can't use gcc later (below), but for now, assume it is impossible.

There are several likely reasons why you haven't heard anything about 
this issue:
1) Many most embedded devices requiring PIC are actually pretty 
primitive. It often easier to give up on something like FT2 and just 
make do with a very simple, small and fast proprietary bitmap font 
library. I have done this myself before. Given the option of writing a 
quick bitmap font renderer (one day of work) or porting FT2.
You don't get the capabilities of FT2, but at you do get some text on 
the screen and it's "good enough".
2) For an embedded product that is a single application and not a 
library, it is sometimes easier to make a quick and dirty hack to get 
FT2 to work. There's a hack allowing GCC to be used for applications.
3) It is possible that a large OEM or SDK maker would base their code on 
FT2, do the work necessary to make it PIC, but simply keep the code to 
itself. These kinds of SDKs are usually not updated very often anyway, 
so doing the work again every time when updating the SDK and FT2 is not 
a very big deal to a large software house.

Personally, I believe there may be quite a few of (3) hanging around and 
we simply don't know about it. I've seen a lot of FT2 discussions on the 
internet, and [ft2] list is full of posts from people from large 
corporations.
Even for my case: I could make the changes by myself and keep the, (and 
I guess from the lack of enthusiasm, I'll have to). The only difference 
here is that we are NOT a big corporation, and we WANT to share our results.

> The general question is whether it makes more sense to port gcc to
> BREW.  You would immediately have access to a lot of code which then
> compiles just fine out of the box.

I would love to drop all proprietary compilers and just work on GCC, but 
that would not be possible. I write "BREW" but please feel free to 
replace that with "proprietary OS" or "small embedded OS with propritary 
compiler":

1) First and foremost, we are making a static library to be used by 
clients. They will not accept ANYTHING other than something compiled by 
the compiler they specify. This is not a guess, but a fact, as this has 
happened again and again. Sometimes they even give us their own 
compilers so that we can compile a version for them.
No matter how much we say "it doesn't matter" or "the library is 
compatible", they don't seem to care.

2) There is a hack around ( http://brew.wardco.com/index.html ) for 
using GCC in BREW.
But its only good for making applications, not for libraries. The 
clients don't use GCC/WinARM to link their applications and we can't 
force them to use it.

Basically, I am stuck with whatever ADS can do :(

Mickey