Re: [ft] cannot open some fonts on mac and linux

[mpsuzuki]

Hi,

# Riccardo, please check google search result for
# keywords "dyld Symbol not found freetype":
#   http://www.google.com/search?q=dyld+Symbol+not+found+freetype
# You can find worldwide weblogs by people confused by
# unexpected Carbon dependency occured in freetype-2.2.1
# (2.2.1 was the only version using Carbon by default).
# That's why I decided to disable Carbon by default.

On Fri, 21 Sep 2007 00:32:35 +0200
"David Turner" <address@hidden> wrote:
>the traditional, and painful, way to deal with this sort of problems
>in a seamless way (at least for the user) is to use dlopen()-style dynamic
>linking to access the "missing" Carbon functions.

>do you think it'd be possible to add this to FreeType, to get rid of the
>--with-old-mac-fonts and related issues ?

I think it's possible.

>I know it's non trivial work, but that would be the right thing to do.

Although I've proposed a replacement by Carbon-free MacOS
font support, I have to agree this pointing out. ftmac.c
provides a few functions that cannot be implemented without
QuickDraw or ATS (getting a font file from QuickDraw/ATS
font name), runtime resolving of Carbon dependency is required
to provide these functions safely.

The expected procedure would be:

step 1: check whether runtime linker has already loaded
        Carbon framework (even if the application developer
        doesn't care Carbon-dependent feature of FreeType,
        some applications load Carbon framework for other
        purpose, e.g. to use native GUI library etc).

step 2: if Carbon framework is not loaded, try to load it.
        if could not load, returniappropriate error.

step 3: if Carbon framework is loaded, try to resolve
        required Carbon-dependent symbols. If could not
        resolve, return appropriate error.

In last year, I've written testing code for step 3 during
the discussion about how to deprecate the legacy Carbon
functions.

The headache is, step 1 + 2 are expected to be implemented
without non-standard frameworks, to avoid unexpected dependency.
If the softwares are built only with POSIX APIs, the binaries
are linked with libSystem.B.dylib only. The external libraries
(e.g. libdl.dylib or CoreFoundation framework) should not be
used even if they provide convenient functions.

The latest libSystem.B.dylib on Mac OS X 10.4 includes dlsym(),
but older libSystem.B.dylib on Mac OS X 10.{0, 1} doesn't.
In such old systems, NSIsSymbolNameDefined() may be used for,
but they are deprecated :-( I have to think over smart
implementation after the investigation of function availabilities
on each Mac OS X revisions. Anyway, I will write small code
to demonstrate on specific platform within 1 month, please wait.

Regards,
mpsuzuki