Re: [Fink-devel] Framework linker flag in Compile script
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
Re: [Fink-devel] Framework linker flag in Compile script
On 02/24/2010 02:42 AM, suzuki toshiya wrote: 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. It can't be included in dependency_libs, though the libtool that built freetype may be new enough to handle -framework flags, the libtool that is building something else might not be, and would break that something's build when it reads libfreetype.la with -framework CoreServices in dependency_libs. We invented the whole inherited_linker_flags to work around this and a similar problem with -pthreads on other platforms (which is broken on e.g. solaris where Sun CC uses -mt and gcc uses -pthreads :/) DISCUSSION -- A. -framework is not popular as the options for C compiler. As far as I am aware all compilers on Mac OS X that do linking are able to grok the -framework flag. So this is not an issue. 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. If it is your package, and you know that you're going to use libtool-2.2.x, then don't quote the -framework XXX flag with -Wl, and it will get put into the .la file. # Although I've not discussed with GNU libtool maintainers # about this issue, I don't hesitate to write a patch for # consistent behaviour. Feel free to post a patch to libtool-patc...@gnu.org (please post a patch against the current development version, which you can either fetch from git or the daily snapshot, see http://www.gnu.org/software/libtool for info on both. I believe there is currently a test case for -framework flag handling, so if you do post a patch, please also expand on the test case. I will review and commit the patch if appropriate. Peter -- Download Intel#174; 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
Re: [Fink-devel] qt4-mac-4.6.2-1 compile failed due to lack of space, recovering identifies Fink issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/10 1:21 PM, Ronald D. Mabbitt wrote: (CC'ing fink-devel, since this is about fink internals as well) Unfortunately, during a huge copying set, the machine ran out of room (I had allowed Fink nearly five gigabytes, apparently that was inadequate), and Fink announced that the install of qt-mac-4.6.2-1 failed. Scrolling up, it appeared to be near the end of a particular install, but the huge number of copies scrolled previous info off the buffer. I tried starting the entire install again, and Fink merely installed the qt-mac-4.6.2-1 deb, and went on to installing qt-mac-doc-4.6.2-1. Here are my questions.. Is it safe to assume that all the files got copied? A bunch of them failed before, and I didn't see them copied immediately during the restart. It's likely something didn't get made, but I couldn't say what. The deb files that are finished, assuming they validate, are probably OK, but I bet there are some that didn't get made. It's hard to say. Fink decided it needed to temporarily remove pcre to install all all the qt packages. Will Fink automatically remember to reinstall it afterwards, or do I have to do this by hand? I would assume fink would try to put them back, I'm not sure of the behavior, but if the disk is still full, it probably can't. You can always reinstall it just to be sure. Note that I'm mainly asking to help identify issues with Fink that may need to be addressed (whether Fink recovers well if the package installation fails due to running out of space), since in the worst case I simply reinstall qt and pcre. However, since reinstalling would take such a long time, and since checking whether Fink 'has good' / 'needs better' error recovery was a good idea anyway, I thought I'd bring it to your attention and find out whether I've anything to worry about or not. ^^; Well, running out of disk space is kind of a catastrophic event, there's only so much that can be done about that. Things like gcc4x and qt4 (and most of kde, for that matter) are very large, and take a decent amount of space while building. There's no graceful way to handle running out of space, because there isn't enough space to save any state that you're out of space in the first place. :) - -- Benjamin Reed a.k.a. Ranger Rick a.k.a. Raccoon Fink Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLhXFdUu+jZtP2Zf4RAmmBAJ90AjTjt2LXatQNRForfeQ5yIwFzQCeKIGq JLQPWAh7V8sHlengRNCN1PI= =POvX -END PGP SIGNATURE- -- Download Intel#174; 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
Re: [Fink-devel] scons 1.2 into stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/10 7:48 PM, Jack Howarth wrote: Can we have the newer scons 1.2 release moved from unstable into stable? The stable release is very old (0.98) and appears to be misbuilding the relax-py package (which uses scons to build). Jack We'll give the maintainer (cc'ed) a chance to express assent. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuF0gkACgkQB8UpO3rKjQ9KCwCeOE20jqtwrV7SU4t/9DodCdnN 0DUAni/P+MIsqLWRwksfClOG5ThHWaM7 =O1U0 -END PGP SIGNATURE- -- Download Intel#174; 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
