Created attachment 126008 [details] [review]
Safer -framework usage

Hrm, without the patch, "-framework Carbon" appears in *.la inherited_linker_flags; with the patch from Comment #1, nothing about Carbon appears anywhere in *.la (I --disable-static when ./configuring glib). I'll talk to some libtool folks to figure out just WTF is going on here...

...who say that they *should* be passed if static lib and not necessary if shared lib (the -framework flag is passed to the linker for the shared lib so dyld makes sure it's loaded to resolve the symbols there). If static, flag *does* need to be propagated, and libtool's internal notes about inherited_linker_flags say that "Currently, these flags are not uniquified and thus accumulate." so probably best for now to leave the flag as-is unpatched and wait for evidence of it causing a symptom. I guess leave this bug open but ignore it...

is this still relevant?

Daniel, Ping.

My gnome sandbox is waaaaay out-of-date, will try it in the next few days and report back.

There are now two places in configure.ac where a "-framework foo" is propagated as a two-word flag and that winds up being published. Fink's packaging dropped the static lib long ago and libtool may well be handling things cleanly for direct access there, so "still an issue, still don't care" at that point. However, fink's packaging handler alerts that the multiword is also going into the .pc files, which is a potential risk (it's used and later processed by tools other than a known-safe one). The standard pkg-config program has a special case to hold "-framework foo" as a single unit when uniquifying and collecting, but it's still fragile towards any other tool that doesn't know this special case (I've seen efforts to fork or reimplement pkg-config, not sure we should rely on them to know about and work around this situation) or somehow else rationally assumes that nonquoted whitespace is a word delimiter.

Created attachment 215667 [details] [review]
Safer -framework usage

Now fixes both instances in configure.ac. For self-consistency, also makes same change in a makefile, but that one only appears to propagate to .la not .pc

(In reply to comment #8)
> Created an attachment (id=215667) [details] [review]
> Safer -framework usage
> 
> Now fixes both instances in configure.ac. For self-consistency, also makes same
> change in a makefile, but that one only appears to propagate to .la not .pc

Would you be willing to do a git checkout and write a commit message?  https://live.gnome.org/GnomeLove/SubmittingPatches

Created attachment 215698 [details] [review]
Safer -framework usage (against git HEAD)

Per Comment #9 (I think...I'm still a novice at using git)

Review of attachment 215698 [details] [review]:

Perfect, thanks!  You're getting things closer to the point where I can be sitting on the beach with a drink in one hand, pressing the accepted-commit-now button with my phone on the other...

(In reply to comment #11)
> Review of attachment 215698 [details] [review]:

Although I do have one question; aren't we exacerbating the problem here by passing -framework twice inside the GLib build itself?  Shouldn't adding it exactly once to LDFLAGS in configure be sufficient?

The flag-passing is indeed redundant in gio/Makefile.am. Here are the key extracted lines:

configure.ac:

AM_CONDITIONAL(OS_COCOA, [test "$glib_have_cocoa" = "yes"])

if test "x$glib_have_cocoa" = "xyes"; then
  AC_DEFINE(HAVE_COCOA, 1, [define to 1 if Cocoa is available])
  LDFLAGS="$LDFLAGS -Wl,-framework,Foundation"
fi

gio/Makefile.am:

if OS_COCOA
libgio_2_0_la_LDFLAGS += -Wl,-framework,Foundation
endif