Hello,
I have fetched a copy of freetype-2.8 source and issued these commands on OSX:
./configure --prefix /tmp/freetype
make install
The first command printed out the following at the end:
Library configuration:
external zlib: yes (autoconf test)
bzip2: yes (autoconf test)
libpng: yes (libpng-config)
harfbuzz: no
After compilation, I observed that the resultant freetype binary links
to png, zlib and bzip2:
otool -L /tmp/freetype/lib/libfreetype.6.dylib
/tmp/freetype/lib/libfreetype.6.dylib:
/tmp/freetype/lib/libfreetype.6.dylib (compatibility version
21.0.0, current version 21.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
version 1.0.5)
/usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version
38.0.0, current version 38.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
However, if I look at the corresponding ftoption.h, the options for
system zlib, png and zlib2 are commented out, leading to an
inconsistency.
I build libraries that link in freetype and I (thought I could) rely
on the macros in ftoption.h to determine how the freetype was
configured (for the purposes of linking zlib etc when linking to the
static library).
Is it a user error not to modify ftoption.h when building freetype
like that? Is the expectation that the library binary and the header
are consistent uncalled for (i.e. am I misusing the installed
ftoption.h to determine freetype's configuration)? As a point of
comparison, if I use the CMake build system, then the ftoption.h
that's installed actually does reflect the binary (because
CMakeLists.txt modifies it in response to its configuration).
Thanks for your guidance.
_______________________________________________
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype
