Re: [ft-devel] Compilation fixes for FreeType on BeOS

[Antoine Leca]

On Friday, September 30, 2005 03:22Z George Williams wrote:
> On cygwin any external references (malloc, printf, etc.) are treated
> as undefined, and a special external declaration is required in the
> code. Similarly (under cygwin) any entry points/variables must be
> specially marked.

Seems like it is pretty standard PE-COFF requirements, i.e. not specific to
Cygwin but will apply as well to any Win32, WinCE u.s.w.

ELF (or the previous Sun|BSD a.out) scheme is more liberal in the way it
allows you to keep the to-be-dynamically-linked symbols as undefined, and it
is the dynamic linker's job to find which .so will satisfy the reference;
while in the Microsoft scheme you are required to name the providing DLL
inside the .EXE.
I have no idea where BeOS stands on this one.

Then the stuff about specially marking (__declspec(dllim/export) etc.) is
about easying the mechanism, and this is similar to the behaviour of
the -fPIC flag for Linux/*nix; the difference is that one is basically local
while the other is basically global, and it shows different initial
decisions in design (efficiency vs. versability); modern GCC have options to
achieve the same degree of local control in Linux, and there are options in
Windows compilers (all fonctions exported) to achieve the global effect;
also, Freetype does have for a long time a mechanism (FT_DECL_EXPORT etc.)
to handle this "transparently" in the code base.

In fact, the marking is required for global variables in the Win32 scheme,
because there is an additional level of indirection. OTOH, ELF reserves a
register, EBX, to hold the address of a table through which all global
variables are addressed. There are tricks to overcome the Win32 limitation
(--enable-auto-import, --enable-runtime-pseudo-reloc in GCC) but I am not
sure they are worthwhile to be activated by default...


Antoine