GNOME Bugzilla – Bug 672777
Error in gdummyfile.c
Last modified: 2018-05-24 13:55:08 UTC
./configure with no options CC libgio_2_0_la-gdummyfile.lo gdummyfile.c: In function 'unescape_string': gdummyfile.c:462:8: error: expected expression before 'in' gdummyfile.c: In function '_g_decode_uri': gdummyfile.c:559:8: error: expected expression before 'in'
Which version do you try to compile?
I tried to compile all versions between from 2.29 to last version
Which compiler is this ?
Mac Snow-Leopard (10.8.6). Building glib (all versions beyond 2.31.6) make fails at gdummyfile.c with the above error. With 2.31.8, there was an OS_CARBON specific backend initiated? Compiling 2.31.6 has no errors. Compiling with gcc-4.7.0
For me too gcc version 4.7.0 20120218 (experimental) compiles fine Glib 2.31.6
Also true with gcc 4.6.2. I am not sure if that is important information. Happy to provide any data needed. Not sure what to fix since gdummyfile.c itself does not seem to have changed from 2.31.6 to 2.31.8.
No further movement on this? Version 2.32.1 does not compile either in case there is perception that we are dealing with an older version of glib and it has fixed itself in the recent incarnation of glib. Definitely a showstopper on the MAC.
I can confirm this, building with GCC 4.8.2 on Mac OS X 10.4.11. This doesn't occur with gcc-4.0, gcc-4.2 or clang. My build logs are here: https://gist.github.com/mistydemeo/2fc344d92d1d3dae7724
I just tested, and I get the identical error on Lion with GCC 4.8.2. I'm building 2.38.1.
This is probably somehow a side effect of us building gio with "-xobjective-c". from gio/Makefile.am: # This is dumb. The ObjC source file should be properly named .m libgio_2_0_la_CFLAGS += -xobjective-c So, what happens if you rename gnextstepsettingsbackend.c to gnextstepsettingsbackend.m, and then remove the line above?
That does fix that specific error! After doing this, unfortunately GCC is choking on one of the standard OS X headers on at least 10.7 (see excerpts here: https://github.com/mxcl/homebrew/issues/23393#issuecomment-26691980). Fortunately, however, this fixes it on others, like 10.4, so it's definitely worth applying.
Created attachment 257808 [details] [review] Patch to rename gnextstepsettingsbackend.c The following patch works for me with clang, Apple GCC, and FSF GCC.
iirc, we didn't call this ".m" because it caused all kinds of issues for automake to have an optionally-included objective C file. William might remember more about the specifics.
The other possibility would be to do something like: noinst_LTLIBRARIES = libgio-objc.la libgio_objc_la_SOURCES = gnextstepsettingsbackend.c libgio_objc_la_CFLAGS = -xobjective-c libgio_2_0_la_LIBADD += libgio-objc.la
Yet another possibility: rename local variables "in" in gdummyfile.c to "in_" or something else.
Created attachment 279553 [details] [review] gio: Rename `in` to `in_` to avoid conflicts with ObjC
Created attachment 279554 [details] [review] build: Separate the Objective C files into their own helper lib This avoid polluting the CFLAGS with -xobjective-c.
I coded both the approach of comment 14 and of comment 15; in the blind, as it happens, because I'd have to restore my build environment on my MacBook. thus, testing is very much welcome.
Created attachment 293408 [details] [review] Revise Emmanuele's second patch so that libgio-objc gets added to libgio's dependencies. Either one works, though the second needed a slight tweak, attached. Please pick one and push it soon.
Review of attachment 293408 [details] [review]: This patch makes sense (and I like it better than the alternative approach of avoiding the word 'in'). One thing I don't understand, though: ::: gio/Makefile.am @@ +527,3 @@ endif +EXTRA_libgio_2_0_la_DEPENDENCIES = $(gio_win32_res) $(gio_def) $(platform_deps) why the EXTRA_ ?
Review of attachment 293408 [details] [review]: I’m going to rebase (minor changes needed) and push this, since John said it worked. ::: gio/Makefile.am @@ +527,3 @@ endif +EXTRA_libgio_2_0_la_DEPENDENCIES = $(gio_win32_res) $(gio_def) $(platform_deps) I suspect because of this (https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html): > The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it.
Pushed to master. Please reopen this bug if it causes problems.
This is causing issue when building with Meson, it wants objc files to be named ".m" imperatively. (In reply to Allison (desrt) from comment #13) > iirc, we didn't call this ".m" because it caused all kinds of issues for > automake to have an optionally-included objective C file. William might > remember more about the specifics. "all kinds of issues" in 2013, does that still happy in 2018? I guess nobody knows... Let's try renamed those files into .m and keep a separate libgio_objc in Makefile.am, then we could just feed meson with those .m and it will supposedly should pick the right compiler.
Created attachment 372166 [details] [review] Rename objective-c files from .c to .m This is required to build those files using Meson.
Review of attachment 372166 [details] [review]: This breaks autotools build on osx because we have to use AC_PROG_OBJC.
(In reply to Xavier Claessens from comment #25) > Review of attachment 372166 [details] [review] [review]: > > This breaks autotools build on osx because we have to use AC_PROG_OBJC. And adding that in a conditional breaks automake... great... I guess we need to write a rule in Makefile.am to rename .m files to .c before compiling them, so we can have proper .m files in git which is the right thing to have.
(In reply to Xavier Claessens from comment #26) > (In reply to Xavier Claessens from comment #25) > > Review of attachment 372166 [details] [review] [review] [review]: > > > > This breaks autotools build on osx because we have to use AC_PROG_OBJC. > > And adding that in a conditional breaks automake... great... I guess we need > to write a rule in Makefile.am to rename .m files to .c before compiling > them, so we can have proper .m files in git which is the right thing to have. That sounds reasonable, and then at least we’ll have a clean build system once we drop autotools.
Created attachment 372187 [details] [review] Rename objective-c files from .c to .m Those files got renamed to .c to work around an automake issue, but Meson needs them to have .m extension. Better rename them at build time in Makefile.am since that's where the workaround is needed.
Created attachment 372193 [details] [review] Rename objective-c files from .c to .m Those files got renamed to .c to work around an automake issue, but Meson needs them to have .m extension. Better rename them at build time in Makefile.am since that's where the workaround is needed.
Created attachment 372195 [details] [review] Rename objective-c files from .c to .m Those files got renamed to .c to work around an automake issue, but Meson needs them to have .m extension. Better rename them at build time in Makefile.am since that's where the workaround is needed.
Review of attachment 372195 [details] [review]: Please push with the two changes below, thanks. ::: gio/Makefile.am @@ +608,3 @@ +# limitation we rename .m files to .c and compile them separately with +# -xobjective-c into an intermediary library. Note that we cannot rename those +# files to .c directly in the source tree because Meson needs the .m extension. Please add a reference to this bug report in the comment. (But otherwise the comment looks great, thanks.) @@ +613,3 @@ + gosxcontenttype.m \ + gosxappinfo.m \ + gcocoanotificationbackend.m Nitpick: Please add a trailing $(NULL) on its own line, so that adding files in future doesn’t add git diff noise; and please sort the files alphabetically.
Comment on attachment 372195 [details] [review] Rename objective-c files from .c to .m Attachment 372195 [details] pushed as e400af9 - Rename objective-c files from .c to .m
This commit broke make dist. Reverted.
Created attachment 372364 [details] [review] Fix missing osx files when running "make dist"
When that patch is accepted, we have to first revert the revert commits.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/528.