GNOME Bugzilla – Bug 793565
GLib does not compile on macOS 10.13 due to .m file naming
Last modified: 2018-03-05 16:51:01 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.
Created attachment 368528 [details] [review] Fix build on macOS Updated attachment, removing one hunk that wasn't supposed to be submitted.
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.
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.
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.
(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.
(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.
(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
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?
Review of attachment 368932 [details] [review]: OK.
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(-)
(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.
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.
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
Review of attachment 369348 [details] [review]: Thanks. Let’s get this in to the 2.56.0 release. If you can look at the test failures, see if there are any bugs filed for them already[1] and either update those bugs or file new ones, then we can try and get those failures fixed for 2.56.1. They’re not going to get fixed for 2.56.0 though. Thanks for your help so far, it’s appreciated! [1]: https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&f0=OP&f1=OP&f10=content&f11=CP&f12=CP&f13=OP&f14=OP&f15=alias&f16=short_desc&f17=status_whiteboard&f18=content&f19=CP&f2=product&f20=CP&f3=CP&f4=CP&f5=OP&f6=OP&f7=alias&f8=short_desc&f9=status_whiteboard&j1=OR&j14=OR&j6=OR&list_id=294493&o10=matches&o15=substring&o16=substring&o17=substring&o18=matches&o2=substring&o7=substring&o8=substring&o9=substring&op_sys=Mac%20OS&query_format=advanced&v10=%22os%22&v15=x&v16=x&v17=x&v18=%22x%22&v2=glib&v7=os&v8=os&v9=os
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.
Fix pushed to master for 2.56.0. Thanks a lot. Any follow-up for test failures can happen in other bugs.