Dear Sirs,
I'm a maintainer of Macintosh-related part of FreeType2.
I want to ask some questions about the expected linker
flag syntax for Mac OS X developers.
BACKGROUND
----------
At present, freetype-config & freetype2.pc return the
linker flag in "-Wl,-framework,xxx" style, when
FreeType2 is configured to be Carbon-dependent.
When GNU libtool creates libfreetype.la, linker flag
in "-Wl,-framework,XXX" style is dropped. libfreetype.la
does not provide framework dependency, although it can
provide zlib dependency (because GNU libtool does not
drop -lz flag).
PROBLEM
-------
The software packages using pkg-config can obtain
framework dependency by pkg-config --libs.
Or, the software packages linking libfreetype.dylib
can ignore framework dependency by chain loading of
runtime linker. So, it seems that the lack of framework
dependency in libfreetype.la is not serious problem
at present.
However, when I build libfreetype without shared library
and build a package statically that does not refer
pkg-config appropriately, the lack of framework dependency
problem arises.
# I do such when I debug FreeType2.
One of the typical example is sample & utility programs
of fontconfig. These programs are not interested in
font rasterization.
The rule to link fc-cache is:
/bin/sh ../libtool --tag=CC --mode=link \
gcc -g -O2 -o fc-cache \
fc-cache.o ../src/libfontconfig.la
Nothing to say, fc-cache itself has no interest in font
rasterization, it only calls FcXXX() library, so it's
reasonable to link libfontconfig.la only (and let libfontconfig.la
tell its own dependency).
libfontconfig.la can provide the dependency info to libfreetype.la.
But current libfreetype.la does not provide the framework dependency.
As a result, the building fontconfig statically, with statically built
freetype2 with Carbon dependency, is failed aslike:
/bin/sh ../libtool --tag=CC --mode=link \
gcc -g -O2 -o fc-cache fc-cache.o ../src/libfontconfig.la
libtool: link: gcc -g -O2 -o fc-cache fc-cache.o \
../src/.libs/libfontconfig.a \
-L/Users/sssa/redhat/BUILD/freetype2-current/freetype2/root/lib \
/usr/lib/libiconv.dylib \
/Users/sssa/redhat/BUILD/freetype2-current/freetype2/root/lib/libfreetype.a \
-lz -lexpat
Undefined symbols:
"_GetHandleSize", referenced from:
_FT_New_Face_From_LWFN in libfreetype.a(ftbase.o)
_FT_New_Face_From_LWFN in libfreetype.a(ftbase.o)
_FT_New_Face_From_FOND in libfreetype.a(ftbase.o)
"_ATSFontFindFromName", referenced from:
_FT_GetFilePath_From_Mac_ATS_Name in libfreetype.a(ftbase.o)
"_Get1Resource", referenced from:
_FT_New_Face_From_LWFN in libfreetype.a(ftbase.o)
_FT_New_Face_From_LWFN in libfreetype.a(ftbase.o)
"_ResError", referenced from:
_FT_FSPathMakeRes in libfreetype.a(ftbase.o)
_FT_New_Face_From_FOND in libfreetype.a(ftbase.o)
_FT_New_Face_From_FOND in libfreetype.a(ftbase.o)
_FT_New_Face_From_Resource in libfreetype.a(ftbase.o)
_FT_New_Face_From_Resource in libfreetype.a(ftbase.o)
...(snip)
POSSIBLE SOLUTION
-----------------
One of the solution would be the change of linker flag syntax
to be inherited to libfreetype.la. If I change "-Wl,-framework,XXX"
style to raw "-framework XXX", GNU libtool copies them to
inherited linker flag of libfreetype.la, aslike:
# Linker flags that can not go in dependency_libs.
inherited_linker_flags=' -framework CoreServices -framework
ApplicationServices'
# I wonder if framework dependency should be included in
# dependency_libs or this.
DISCUSSION
----------
A. "-framework" is not popular as the options for C compiler.
There is a possibility that some GCC does not know "-framework"
option and it makes compiling/linking failed. In the case that
GCC does not know "-framework" but the linker knows it,
"-Wl,-framework,XXX" is preferred. In my investigation, genuine
GCC knows "-framework" option after gcc-3.3.6. It was the earliest
version that separated darwin-specific part from RS/6000 files,
so I guess, the people using GCC without "-framework" for the
development for Darwin/Mac OS X is quite rare.
B. What should be fixed is GNU libtool, not library packages.
There would be an opinion: the current GNU libtool behaviour:
- "-framework XXX" is copied to .la file.
- "-Wl,-framework,XXX" is NOT copied to .la file.
is inconsistent, if this inconsistency is the reason to
change from "-Wl,-framework,XXX" to "-framework XXX",
what should be fixed is primarily GNU libtool inconsistency,
changing in the side of library package is not good idea.
# Although I've not discussed with GNU libtool maintainers
# about this issue, I don't hesitate to write a patch for
# consistent behaviour.
C. raw "-framework" option can be broken by GNU libtool.
As Ebrahim reported already, deb package validator warns that
it is unsafe because GNU libtool can transform the flags to
unwanted flags (I'm not sure what "munge" means, I guess
something like an incorrect splitting of "-framework" and
"name_of_framework"). For safe transfer of linker options,
"-Wl,-framework,XXX" is better. Completely I agree.
It seems that latest GNU libtool is aware of "-framework" and
"-F" (path specification for framework), and I guess the danger
of breaking raw "-framework" options is fixed. If I'm
misunderstanding the reason why raw "-framework" should be
avoided, please let me know. I wish if concrete example of
raw "-framework" option is broken by GNU libtool.
-----
In summary, I want to ask the comments about using raw
"-framework" option in FreeType library. Please let me know
your thought.
Regards,
mpsuzuki
On Mon, 04 Jan 2010 09:58:40 -0500
Alexander Hansen <alexanderk.han...@gmail.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 1/4/10 8:03 AM, Ebrahim Mayat wrote:
>> On Mon, 2010-01-04 at 11:31 +0100, Martin Costabel wrote:
>>
>>> I think what the validator wants is
>>>
>>> LDFLAGS=-Wl,framework,CoreFoundation
>>>
>>> Like this, a too eagerly alphabetically-sorting libtool cannot destroy
>>> the flag.
>>>
>> Many thanks, Martin! Adding
>>
>> SetLDFLAGS: -Wl, -framework,CoreFoundation
>>
>> did the trick.
>>
>> BTW, I have also added the following two fields:
>>
>> Distribution: 10.4
>> Architecture: powerpc
>>
>> I was thinking of opening another tracker item since the package
>> description file for 10.5 is slightly different. Would this be the right
>> way to do it ?
>>
>> Regards,
>> Ebrahim
>>
>>
>
>That wouldn't be a bad idea. Since it's going to require separate
>machines to test the descriptions, that will make it easier to add them
>as they get tested.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
