Re: [ft-devel] Conditionalize Bzip2-compressed font support for inflexible dynamic linker platforms
> During the business trip, I was trying to reproduce the trouble that > Dave Viner got in > http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html , > and I found I made an overestimation about bad impact of the chained > dependency. Please let me explain. [...] Thanks for the analysis! I'm now going to prepare a new release. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Conditionalize Bzip2-compressed font support for inflexible dynamic linker platforms
Dear Werner, Just I've finished 2 international meetings. On Mon, 04 Apr 2011 05:37:33 +0200 (CEST) Werner LEMBERG wrote: >You must have a special procedure in mind which I haven't grasped yet. >I know nothing about the linker on Macs, I just wonder why zlib is >handled differently compared to bzip2... During the business trip, I was trying to reproduce the trouble that Dave Viner got in http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html , and I found I made an overestimation about bad impact of the chained dependency. Please let me explain. Abstract I think Mac OS X won't be the platform that the introduction of new library dependency cause serious problems. So I cancell my proposal from urgent issue and postpone it until the day when we receive a request of the smooth migration (for "configure && make && make install" people) on inflexible runtime linker. My concern == Some inflexible runtime linker does not support the chained dependency. For such linkers, all shared libraries must be explicitly given via command line option to the linker when a binary executable is linked. Some inflexible runtime linker does not support lazy binding and prevent the execution when an unresolved symbol is found during the runtime linking. Considering about the inflexible linker without the chained dependency and lazy binding, following scenario may occur by the introduction of the dependency for new library. The program built with older libfreetype2 without bzip2 support depends on standard C, libfreetype, and zlib (maybe). Because of the lack of chained dependency support, zlib dependency is written to the binary executable. 2.x.y - libfreetype +-> standard C +-> zlib prog_using_libfreetype +-> standard C +-> libfreetype +-> zlib Considering the case that we replaced libfreetype by newer version with bzip2 support. The binary executable linked with older version doesn't know about bzip2 dependency, so the runtime linker cannot resolve the dependency. 2.x.(y+1) - libfreetype +-> standard C +-> zlib +-> bz2 prog_using_libfreetype +-> standard C +-> libfreetype +-> zlib ( +-> bz2 ) If the runtime linker cannot stand with unresolved symbol to bzip2 library (or, the execution tries to use the symbol in bzip2), the execution will fail. I was thinking such breaking occured for Mac OS X Carbon/ QuickDraw functions (used to support resource-fork fonts). Dave Viner case === However, the trouble that Dave Viner was different from the case described in above. Mac OS X runtime linker seems to support the chained dependency (yet I've not checked the lowest version supporting it, but versions >= 10.3 supports it, at least). If I build freetype-2.2.1 on Mac OS X with Carbon/QuickDraw functions, the built libfreetype lacks the dependency info about Carbon/QuickDraw (the dependency to zlib is included). It means that the linker option to build libfreetype was insufficient. In addition, freetype-config of 2.2.1 didn't include Carbon/QuickDraw dependency. Of course, these problems were already fixed. So what? Although my previous experience about Carbon/QuickDraw unresolved symbol was really MacOS-specific issue, most modern Unix platforms may support the chained dependency and lazy binding. Thus, we can postpone this issue until the day when we receive the request for improvement with concrete examples. Additional info === Talking about the bundled bzip2 library bun, the historical changes of Mac OS X is following: Mac OS X 10.0: no bzip2, no libbz2. Mac OS X 10.1: no bzip2, no libbz2. Mac OS X 10.2: ? (I don't have this version) Mac OS X 10.3: bzip2, libbz2.a Mac OS X 10.4: bzip2, libbz2.dylib (no archive library) Mac OS X 10.5: bzip2, libbz2.dylib (no archive library) So the developers should be careful when they use back- compatible SDK. But libbz2.a bundled to Mac OS X 10.3 can be linked in dynamic libfreetype. So it won't be a fatal issue. Regards, mpsuzuki >The name of this new command line argument is quite cryptic. If at >all, shouldn't this be `--enable-new-dependencies'? Could you find a >better name which is derived from the option's functionality instead >of the compatibility to older versions? Indeed. Considering the case that the installer of current/ existing version and the installer of next version may be different, "new" is not intuitive, such naming is not good. The compatibility check by existing freetype-config would be better... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Conditionalize Bzip2-compressed font support for inflexible dynamic linker platforms
Hi all,
The latest FreeType2 on GIT repository supports Bzip2-compressed
font files which are used in Ubuntu GNU/Linux platform. It uses
Bzip2 library out of FreeType2, so FreeType2 with this feature has
new inter-library dependency (older does not depends on libbz2 but
newer depends). There can be some unresolved symbol problems on
the platform with inflexible dynamic linker that cannot resolve
the chained inter-library dependency.
# One of the typical inter-library dependency problem is found
# on Mac OS X, see:
#
# http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html
To prevent the trouble, I wrote a patch to do following workarounds:
1) detect the inflexible platforms by GNU libtool configuration result,
by using link_all_deplibs value.
1-a) LT_INIT() is moved before library checking (zlib, bzip2lib)
1-b) Mac OS X compiler/linker flag harmonization is moved before LT_INIT().
2) detect if "-lbz2" links shared version of libbz2, by checking
the symbols in linked binary. if the system has only static
library for libbz2, there wouldn't be such problem.
AC_CHECK_LIB() is decomposed to more low-level shell script
to check the status of the symbols from linked binary.
3) detect if the user tries to ignore the inter-library dependency,
by new option to configure "--enable-new-dependency".
By this patch, "configure && make" on GNU/Linux (maybe most modern
Unix platforms using ELF format) will enable Bzip2-compression by
default, but "configure && make" on Mac OS X will disable it by
default.
Please comment if this is too coward attitude, or too dirty/lengthy
in comparison with the impact of the problem.
Regards,
mpsuzuki
diff --git a/docs/CHANGES b/docs/CHANGES
index 61442ec..310268f 100644
--- a/docs/CHANGES
+++ b/docs/CHANGES
@@ -20,7 +20,10 @@ CHANGES BETWEEN 2.4.4 and 2.4.5
- Support for PCF files compressed with bzip2 has been contributed
by Joel Klinghed. To make this work, the OS must provide a
- bzip2 library.
+ bzip2 library. To prevent the unresolved symbol troubles, this
+ feature is disabled by default on the platforms without flexible
+ linker (e.g. Mac OS X). New option "--enable-new-dependency" is
+ added to configure script to enable the feature forcibly.
- Bradley Grainger contributed project and solution files in
Visual Studio 2010 format.
diff --git a/ChangeLog b/ChangeLog
index 86a9468..88ff7cb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2011-04-01 suzuki toshiya
+
+ * builds/unix/configure.raw: Check linker flexibility for Bzip2.
+ If the dynamic linker is inflexible and GNU libtool mark it as
+ all dependency libraries must be linked explicitly (e.g. Mac OS X),
+ the support for Bzip2-compressed fonts is disabled to prevent
+ the troubles of unresolved symbols of libbz2. To enable the
+ feature forcibly, "--enable-new-dependency" option is introduced.
+
2011-03-30 Werner Lemberg
* src/autofit/aftypes.h (AF_OutlineRec): Removed, unused.
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index a58d20c..0a53504 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -213,36 +213,6 @@ AC_SUBST([FTSYS_SRC])
AC_CHECK_FUNCS([memcpy memmove])
-
-# check for system zlib
-
-# don't quote AS_HELP_STRING!
-AC_ARG_WITH([zlib],
- AS_HELP_STRING([--without-zlib],
- [use internal zlib instead of system-wide]))
-if test x$with_zlib != xno && test -z "$LIBZ"; then
- AC_CHECK_LIB([z], [gzsetparams], [AC_CHECK_HEADER([zlib.h], [LIBZ='-lz'])])
-fi
-if test x$with_zlib != xno && test -n "$LIBZ"; then
- CFLAGS="$CFLAGS -DFT_CONFIG_OPTION_SYSTEM_ZLIB"
- LDFLAGS="$LDFLAGS $LIBZ"
- SYSTEM_ZLIB=yes
-fi
-
-# check for system libbz2
-
-# don't quote AS_HELP_STRING!
-AC_ARG_WITH([bzip2],
- AS_HELP_STRING([--without-bzip2],
- [do not support bzip2 compressed fonts]))
-if test x$with_bzip2 != xno && test -z "$LIBBZ2"; then
- AC_CHECK_LIB([bz2], [BZ2_bzDecompress], [AC_CHECK_HEADER([bzlib.h],
[LIBBZ2='-lbz2'])])
-fi
-if test x$with_bzip2 != xno && test -n "$LIBBZ2"; then
- CFLAGS="$CFLAGS -DFT_CONFIG_OPTION_USE_BZIP2"
- LDFLAGS="$LDFLAGS $LIBBZ2"
-fi
-
# Some options handling SDKs/archs in CFLAGS should be copied
# to LDFLAGS. Apple TechNote 2137 recommends to include these
# options in CFLAGS but not in LDFLAGS.
@@ -286,6 +256,96 @@ do
done
set ${save_config_args}
+# switch to permit the incompatible dependency of libfreetype.
+AC_ARG_ENABLE([new-dependency],
+ AS_HELP_STRING([--enable-new-dependency],
+ [allow linking with the shared libraries that
+ older freetype2 didn't use (default=no), only
+ for the platform with inflexible linker.]))
+
+# initialize GNU libtool before checking of other libraries,
+# to predict the chained dependency issue by ${link_all_deplibs}.
+LT_INIT(win32-dll)
+
+# check for sy
