GNOME Bugzilla – Bug 668152
-framework Carbon linker flag not passed to pkg-config .pc files
Last modified: 2014-04-01 18:26:12 UTC
Created attachment 205497 [details] [review] Patch to pass "-framework Carbon" into gthread pkg-config file When building on OS X the presence of Carbon is detected and it adds a dependency on the Carbon framework. If you use pkg-config to get the required LDFLAGS for your application "-framework Carbon" isn't there, however is a necessary part of the command line. Ideally "-framework Carbon" would end up in the right place in the .pc files where it is required. A working, but entirely insufficient patch that helped me get past this problem is attached. Insufficient because it only affects the gthread .pc file (I'm not sure what others also need this, I'm just trying to get Qemu compiling which only uses gthread), additionally, I'm directly editing the configure file, because my knowledge of autoconf is poor. Of course, maybe this is a bug with how I've configured the library, but that wasn't obvious. Alternatively it is a bug in the Qemu build which should explicitly add '-framework Carbon' to its LDFLAGS, but that doesn't really seem right.
I ran into this while helping someone build some software which uses glib on a Mac. However, the problem didn't manifest itself when we initially used a dynamic version of glib; it was only when we moved on to do a static link that it failed. I therefore think that the "-framework Carbon" should only be added to Libs.private. I worked around the problem with ./configure LDFLAGS="-framework Carbon" when building the glib-using application so I haven't actually tested this theory.
Comment on attachment 205497 [details] [review] Patch to pass "-framework Carbon" into gthread pkg-config file [Setting "patch" flag and correcting mime type]
Review of attachment 205497 [details] [review]: thanks for your patch. the configure chunk should not be in the patch. also, the patch appears to be reversed. could you please attach a new version? it would be brilliant if you could use `git format-patch` so that we can properly credit you.
You are right, the patch is reversed. My bad. To fix this properly though, it needs to go in to whatever actually generates the configure scripts, and to be perfectly honest, I really don't know auto* well enough to even guess about where to put this. If someone can point me in the right direction as to where in the twisty maze of .am and .in files I might look I can give it a go, but this probably needs someone with more experience than me.
(In reply to comment #1) > I ran into this while helping someone build some software which uses glib on a > Mac. However, the problem didn't manifest itself when we initially used a > dynamic version of glib; it was only when we moved on to do a static link that > it failed. I therefore think that the "-framework Carbon" should only be added > to Libs.private. I agree with the conclusion here: no need to propagate this flag to everyone who would ever link against this lib. It's not part of the *public* interface, but only a private implementation detail, which is why it's not needed when the lib is dynamic (shared lib links against its direct dependencies) but is when it's static (top-level needs to link directly against everything because no dyld in a static world). And .private seems exactly the mechanism pkg-config supplies for this sort of thing.
Created attachment 272478 [details] [review] build: Include Cocoa/Carbon in Libs.private if targetting Mac OS X This allows static linking against GIO on OS X, which would previously fail due to unresolved symbols from the above two frameworks.
See also: bug #725894.
Created attachment 273392 [details] [review] build: Include Cocoa/Carbon in Libs.private if targetting Mac OS X This allows static linking against GIO on OS X, which would previously fail due to unresolved symbols from the above two frameworks.
Review of attachment 273392 [details] [review]: looks good to me.
Comment on attachment 273392 [details] [review] build: Include Cocoa/Carbon in Libs.private if targetting Mac OS X Thanks for the review. Pushed to master. commit 8d037c678d8d3d0c0e4e1ddb22e47306567ed88a Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Thu Mar 20 12:32:36 2014 +0000 build: Include Cocoa/Carbon in Libs.private if targetting Mac OS X This allows static linking against GIO on OS X, which would previously fail due to unresolved symbols from the above two frameworks. https://bugzilla.gnome.org/show_bug.cgi?id=668152 configure.ac | 14 +++++++++----- gio-2.0.pc.in | 2 +- glib-2.0.pc.in | 2 +- 3 files changed, 11 insertions(+), 7 deletions(-)