Dear Werner, Just I've finished 2 international meetings.
On Mon, 04 Apr 2011 05:37:33 +0200 (CEST) Werner LEMBERG <[email protected]> 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 [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
