Dear Werner,
Just I've finished 2 international meetings.
On Mon, 04 Apr 2011 05:37:33 +0200 (CEST)
Werner LEMBERG w...@gnu.org 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
