After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793565 - GLib does not compile on macOS 10.13 due to .m file naming
GLib does not compile on macOS 10.13 due to .m file naming
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
unspecified
Other Mac OS
: Normal blocker
: 2.56
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2018-02-18 16:09 UTC by Michael 'Mickey' Lauer
Modified: 2018-03-05 16:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix build on macOS (2.55 KB, application/mbox)
2018-02-18 16:09 UTC, Michael 'Mickey' Lauer
  Details
Fix build on macOS (2.02 KB, patch)
2018-02-18 18:24 UTC, Michael 'Mickey' Lauer
none Details | Review
Fix build on macOS (1.62 KB, patch)
2018-02-26 12:15 UTC, Michael 'Mickey' Lauer
committed Details | Review
Link against AppKit (953 bytes, patch)
2018-03-05 14:57 UTC, Michael 'Mickey' Lauer
committed Details | Review

Description Michael 'Mickey' Lauer 2018-02-18 16:09:31 UTC
Created attachment 368519 [details]
Fix build on macOS

glib does not compile on macOS 10.13. With recent clang versions, files containing Objective-C code need to have the '.m' extension. The attached patch fixes this.
Comment 1 Michael 'Mickey' Lauer 2018-02-18 18:24:27 UTC
Created attachment 368528 [details] [review]
Fix build on macOS

Updated attachment, removing one hunk that wasn't supposed to be submitted.
Comment 2 Philip Withnall 2018-02-19 11:42:25 UTC
Which version of GLib are you trying to build? The latest tarball release, or git master?

A fix was recently pushed for bug #672777 which is very related to this. The reason that the files are named .c rather than .m is apparently because automake doesn’t behave well with conditionally included .m files: https://bugzilla.gnome.org/show_bug.cgi?id=672777#c13.
Comment 3 Michael 'Mickey' Lauer 2018-02-19 12:18:55 UTC
I'm always working against master. Unfortunately I don't know anything about another way to make clang pick up the correct mode of operation. Moving the files here made it work instantly, that's all I can report.
Comment 4 Michael 'Mickey' Lauer 2018-02-19 14:20:26 UTC
Ok, I just learned about -xobjective-c. Apparently this can be used to force the language mode (thus allowing .c files to be compiled in Objective-C mode). Now another way to fix this issue would be to find out why it isn't picked up for the build.
Comment 5 Philip Withnall 2018-02-19 14:27:14 UTC
(In reply to Michael 'Mickey' Lauer from comment #4)
> Now another way to fix this issue would be to find out why it isn't
> picked up for the build.

I would prefer a fix like that, which saves further messing around with autotools to test whether the problem with conditional .m files is still actually a problem.
Comment 6 Philip Withnall 2018-02-20 12:12:28 UTC
(In reply to Michael 'Mickey' Lauer from comment #4)
> Now another way to fix this issue would be to find out why it isn't
> picked up for the build.

If you could find time to do that, that would be appreciated. I don’t have an OS X machine to test on.
Comment 7 Philip Withnall 2018-02-26 11:22:31 UTC
(In reply to Philip Withnall from comment #6)
> (In reply to Michael 'Mickey' Lauer from comment #4)
> > Now another way to fix this issue would be to find out why it isn't
> > picked up for the build.
> 
> If you could find time to do that, that would be appreciated. I don’t have
> an OS X machine to test on.

We’ve got a week until the code freeze for 2.56. If you would like GLib 2.56 to be buildable on OS X, please can you look into updating the patch to use (or fix use of) -xobjective-c? As I said, I cannot test this, so cannot fix it. Thanks.

https://wiki.gnome.org/Schedule
Comment 8 Michael 'Mickey' Lauer 2018-02-26 12:15:12 UTC
Created attachment 368932 [details] [review]
Fix build on macOS

It turns out 80d328b3a8bbfea402f9909e8effbde1ea102271 was not taking all the Objective-C files into account.

GLib at least _builds_ fine now, tested on macOS 10.13.3 (High Sierra).

For some reason though I still get missing symbol warnings for the tests, such as:

dyld: Symbol not found: _OBJC_CLASS_$_NSImage
  Referenced from: /Users/mickey/Documents/late/misc/glib/gio/.libs/libgio-2.0.0.dylib
  Expected in: flat namespace
 in /Users/mickey/Documents/late/misc/glib/gio/.libs/libgio-2.0.0.dylib

NSImage is provided by AppKit, which is supposed to be linked through -Wl,framework,AppKit as found in 

libgio_objc_2_0_la_LDFLAGS = $(libgio_2_0_la_LDFLAGS) -Wl,-framework,Foundation -Wl,-framework,AppKit

If we link to AppKit in libgio_obc_2_0 we don't need to state it again for the individual binaries or do we?
Comment 9 Philip Withnall 2018-02-27 11:03:54 UTC
Review of attachment 368932 [details] [review]:

OK.
Comment 10 Philip Withnall 2018-02-27 11:06:17 UTC
Comment on attachment 368932 [details] [review]
Fix build on macOS

Pushed to master, thanks.

commit 170466db26818ade10862ff405698bb7a97d6d8e (HEAD -> master, origin/master, origin/HEAD)
Author: Dr. Michael Lauer <mickey@vanille-media.de>
Date:   Mon Feb 26 13:08:27 2018 +0100

    gio: fix compiling on macOS by moving all Objective-C file into libgio-objc-2.0
    
    Previously, only gnextstepsettingsbackend.c was taken into account.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=793565

 gio/Makefile.am | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)
Comment 11 Philip Withnall 2018-02-27 11:07:11 UTC
(In reply to Michael 'Mickey' Lauer from comment #8)
> If we link to AppKit in libgio_obc_2_0 we don't need to state it again for
> the individual binaries or do we?

I’m not sure how the linker on OS X works. Try it and see.
Comment 12 Philip Withnall 2018-03-05 13:20:27 UTC
Can you please test and provide any more necessary patches before Wednesday (7th) at the latest, if you want the 2.56.0 release to be buildable on OS X. Today is the hard code freeze: Wednesday is the release date. https://wiki.gnome.org/ThreePointTwentyseven

As I can’t test this myself, GLib will get released without support for being built on OS X unless you can help. Thanks.
Comment 13 Michael 'Mickey' Lauer 2018-03-05 14:57:01 UTC
Created attachment 369348 [details] [review]
Link against AppKit

At least on my system (macOS 10.13.x High Sierra), I have to apply this patch to make the tools that ship with glib (e.g., gdbus) start. Without this patch dyld complains about an unresolved symbol NSImage (which happens to reside in AppKit). 

Being more an iOS developer than a Cocoa developer, I'm not sure why -Wl,-framework AppKit is not enough to have in libgio_objc_2_0_la_LDFLAGS.

The tests seem to run both with and without this patch though:

Testsuite summary for glib 2.55.2
============================================================================
# TOTAL: 3831
# PASS:  3824
# SKIP:  5
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 2
Comment 15 Philip Withnall 2018-03-05 15:25:08 UTC
A corresponding change has to be made to COCOA_LIBS in meson.build, but I can do that when merging. Requesting a freeze break now.
Comment 16 Philip Withnall 2018-03-05 16:50:58 UTC
Fix pushed to master for 2.56.0. Thanks a lot. Any follow-up for test failures can happen in other bugs.