Fix build with --with-included-glib on Darwin

[Dan Nicholson]

On Sat, Feb 27, 2016 at 10:02 PM, Dan Nicholson <nicholson at endlessm.com> wrote:
> On Feb 27, 2016 1:16 PM, "Adam Mercer" <ramercer at gmail.com> wrote:
>>
>> On Fri, Feb 26, 2016 at 11:14 AM, Dan Nicholson <nicholson at endlessm.com>
>> wrote:
>>
>> > Sorry for being slow on this. This is also
>> > https://bugs.freedesktop.org/show_bug.cgi?id=92902. Upstream seems to
>> > have fixed this slightly differently. Can you try out the following
>> > patch?
>> >
>> > https://git.gnome.org/browse/glib/commit/?id=8d037c678
>>
>> Looks like the patch reference above is for glib so I applied the
>> configure.ac hunk to glib/configure.ac, then then ran:
>>
>> $ autoreconf -iv
>> $ ../configure --with-internal-glib
>> $ make
>>
>> and that failed with the same error as before:
>>
>> $ make
>> <snip>
>> Making all in .
>>   CC       pkg.o
>>   CC       parse.o
>>   CC       rpmvercmp.o
>>   CC       main.o
>>   CCLD     pkg-config
>> Undefined symbols for architecture x86_64:
>>   "_CFRelease", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_CFStringGetCString", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_CFStringGetCStringPtr", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_CFStringGetLength", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_CFURLCopyFileSystemPath", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_CFURLCreateFromFSRef", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_FSFindFolder", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>>   "_kCFAllocatorSystemDefault", referenced from:
>>       _find_folder in libglib-2.0.a(libglib_2_0_la-gutils.o)
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> make[2]: *** [pkg-config] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> $
>>
>> glib itself builds fine, the problem seems to be in linking pkg-config
>> against the internal glib.
>
> Thanks for testing. That makes sense now that I think of it. That's why the
> upstream patch is against the glib pc files, which we can't use here since
> we can't use pkg-config. We'll have to duplicate the logic like in Rudá's
> patch.

Interesting. Seems this got broken a long time ago in
https://bugzilla.gnome.org/show_bug.cgi?id=566994, which only came to
pkg-config when glib got updated in the last release. Glib's configure
used to set "-framework Carbon" and "-framework Foundation". Libtool
has special support for that format and it got pulled in from the
libglib-2.0.la file. However, the new format of -Wl,-framework,Carbon
-Wl,-framework,Foundation doesn't get pulled in by libtool and then
doesn't get applied when linking pkg-config.

I don't really want to carry a separate platform check in pkg-config's
configure, so I wonder if you could see if the attached patch fixes
things. Could you show the contents of glib/glib/libglib-2.0.la in
both cases?

Thanks,
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osx-static-framework.patch
Type: text/x-patch
Size: 1146 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pkg-config/attachments/20160229/8a92c4b8/attachment.bin>