Re: [Fink-devel] Framework linker flag in Compile script
Dear Peter, On Wed, 24 Feb 2010 10:02:32 -0600 Peter O'Gorman pe...@pogma.com wrote: On 02/24/2010 02:42 AM, suzuki toshiya wrote: 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. Thank you for comment. Just I've submitted a patch to pick -framework options from -Wl, and -Xlinker flags. I think I received no comment from the viewpoint of Fink maintainers. I want to hear the comments about my proposal checking the content of -Wl, quoted flags. http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg1.html Although I noted an opinion requesting the consistent behaviour between raw -framework versus quoted -Wl,-framework, there can be an objection like: The latest GNU libtool's handling of raw -framework is good, but more longer time is needed to be populated broadly and agreed to be safe (e.g. Fink still provides freetype-2.1.4 binary package, the version released on 2003). The preference to -Wl, quoted flag is based on its transparency. The proposed patch breaks its transparency (and disturbs long time testing), so it is not useful but harmful. I want to hear the comment from Fink maintainers about the detailed parsing of -Wl, quoted flags by GNU libtool. Regards, mpsuzuki -- 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] Framework linker flag in Compile script
On Tue, Mar 02, 2010 at 06:40:46PM +0900, mpsuz...@hiroshima-u.ac.jp wrote: Dear Peter, On Wed, 24 Feb 2010 10:02:32 -0600 Peter O'Gorman pe...@pogma.com wrote: On 02/24/2010 02:42 AM, suzuki toshiya wrote: 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. Thank you for comment. Just I've submitted a patch to pick -framework options from -Wl, and -Xlinker flags. I think I received no comment from the viewpoint of Fink maintainers. I want to hear the comments about my proposal checking the content of -Wl, quoted flags. http://lists.gnu.org/archive/html/libtool-patches/2010-03/msg1.html Although I noted an opinion requesting the consistent behaviour between raw -framework versus quoted -Wl,-framework, there can be an objection like: The latest GNU libtool's handling of raw -framework is good, but more longer time is needed to be populated broadly and agreed to be safe (e.g. Fink still provides freetype-2.1.4 binary package, the version released on 2003). The preference to -Wl, quoted flag is based on its transparency. The proposed patch breaks its transparency (and disturbs long time testing), so it is not useful but harmful. I want to hear the comment from Fink maintainers about the detailed parsing of -Wl, quoted flags by GNU libtool. What does this have to do with fink? Fink just wants things to Work(tm), and our maintainers able to cope with whatever packages do. We don't write libtool, we don't patch libtool locally, we don't have fink-specific behavior. Fink is just a perl-script that calls system(./configure --prefix=/sw make) and such. As idiosyncratic as libtool can be, it's easy to use it and get something that works as long as the author of the package fink is compiling actually uses libtool per its manual and doesn't subvert its magic. If those authors are not using things correctly for whatever libtool they are distributing, that's their bug; fink folks just whine about they are distributing something broken and hack around it without really distinguishing blame to libtool vs the author who is mis-using libtool. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- 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] 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] Framework linker flag in Compile script
Ebrahim Mayat wrote: [] CompileScript: ./configure %c LDFLAGS=-framework CoreFoundation make I still get the following complaint: Validating .deb dir /sw/src/fink.build/root-fluidsynth-dev-1.1.1-280... Error: The -framework flag may get munged by libtool. See the gcc manpage for information about passing multi-word options to flags for specific compiler passes. Offending file: /sw/lib/libfluidsynth.la Offending line: inherited_linker_flags=' -framework CoreFoundation' I think what the validator wants is LDFLAGS=-Wl,framework,CoreFoundation Like this, a too eagerly alphabetically-sorting libtool cannot destroy the flag. -- Martin -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ 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] Framework linker flag in Compile script
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 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ 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] Framework linker flag in Compile script
-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. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktCAiAACgkQB8UpO3rKjQ/p6gCfe7GMVg3m5aXPTPl+97fqeypM Vc0An3blqK2sRbXAW4Zrh0309URawq+n =CLN0 -END PGP SIGNATURE- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ 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
