This repository has been archived by the owner. It is now read-only.

glib fails to build with gcc 4.8.2 on Lion #23393

Closed
mistydemeo opened this Issue Oct 20, 2013 · 7 comments

Comments

2 participants
@mistydemeo
Contributor

mistydemeo commented Oct 20, 2013

Logs: https://gist.github.com/mistydemeo/2fc344d92d1d3dae7724

A couple of errors in gdummyfile.c:

libtool: compile: gcc-4.8 -DHAVE_CONFIG_H -I. -I.. -I/usr/local/Cellar/zlib/1.2.8/include -DG_LOG_DOMAIN=\"GLib-GIO\" -I.. -I../glib -I../glib -I.. -I../gmodule -DG_DISABLE_CAST_CHECKS -DGIO_COMPILATION -DGIO_MODULE_DIR=\"/usr/local/lib/gio/modules\" -I/usr/local/opt/zlib/include -I/usr/local/opt/gettext/include -F/usr/local/Frameworks -D_REENTRANT -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format=2 -Werror=missing-include-dirs -fvisibility=hidden -xobjective-c -Os -w -pipe -mcpu=7450 -faltivec -mmacosx-version-min=10.4 -c gdummyfile.c -fno-common -DPIC -o .libs/libgio_2_0_la-gdummyfile.o
gdummyfile.c: In function 'unescape_string':
gdummyfile.c:462:8: error: expected expression before 'in'
for (in = escaped_string; in < escaped_string_end; in++)
^
gdummyfile.c: In function '_g_decode_uri':
gdummyfile.c:559:8: error: expected expression before 'in'
for (in = uri; in < p - 1; in++)
^

This doesn't happen with any Apple compilers.

(Note that the logs are from Tiger, but the same thing happens on x86_64 Lion with GCC 4.8.2.)

Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=672777

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 20, 2013

Contributor

The functions themselves seem harmless enough, unless I'm missing something:

static char *
unescape_string (const gchar *escaped_string,
         const gchar *escaped_string_end,
         const gchar *illegal_characters)
{
  const gchar *in;
  gchar *out, *result;
  gint character;

  if (escaped_string == NULL)
    return NULL;

  if (escaped_string_end == NULL)
    escaped_string_end = escaped_string + strlen (escaped_string);

  result = g_malloc (escaped_string_end - escaped_string + 1);

  out = result;
  for (in = escaped_string; in < escaped_string_end; in++) 

...
Contributor

mistydemeo commented Oct 20, 2013

The functions themselves seem harmless enough, unless I'm missing something:

static char *
unescape_string (const gchar *escaped_string,
         const gchar *escaped_string_end,
         const gchar *illegal_characters)
{
  const gchar *in;
  gchar *out, *result;
  gint character;

  if (escaped_string == NULL)
    return NULL;

  if (escaped_string_end == NULL)
    escaped_string_end = escaped_string + strlen (escaped_string);

  result = g_malloc (escaped_string_end - escaped_string + 1);

  out = result;
  for (in = escaped_string; in < escaped_string_end; in++) 

...
@manphiz

This comment has been minimized.

Show comment
Hide comment
@manphiz

manphiz Oct 21, 2013

Contributor

The problem seems to be that on Mac sources for libgio is being compiled as objective-c sources (see gio/Makefile.am:504), but GNU GCC doesn't handle this well. When I dropped the "-xobjective-c" switch it works. I'll update upstream bug report with more details.

Contributor

manphiz commented Oct 21, 2013

The problem seems to be that on Mac sources for libgio is being compiled as objective-c sources (see gio/Makefile.am:504), but GNU GCC doesn't handle this well. When I dropped the "-xobjective-c" switch it works. I'll update upstream bug report with more details.

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 21, 2013

Contributor

Upstream had a similar suggestion:

 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?
Contributor

mistydemeo commented Oct 21, 2013

Upstream had a similar suggestion:

 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?
@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 21, 2013

Contributor

Hilariously, when I apply the recommended patch, GCC appears to choke on a core OS header instead:

In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:120:0,
                 from gnextstepsettingsbackend.m:28:
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:75:24: error: expected identifier or '(' before '^' token
 @property (copy) void (^terminationHandler)(NSTask *) NS_AVAILABLE(10_7, NA);
                        ^
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:78:1: error: expected identifier before 'end'
 @end
 ^

Which I can't really blame on GNOME.

Contributor

mistydemeo commented Oct 21, 2013

Hilariously, when I apply the recommended patch, GCC appears to choke on a core OS header instead:

In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:120:0,
                 from gnextstepsettingsbackend.m:28:
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:75:24: error: expected identifier or '(' before '^' token
 @property (copy) void (^terminationHandler)(NSTask *) NS_AVAILABLE(10_7, NA);
                        ^
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:78:1: error: expected identifier before 'end'
 @end
 ^

Which I can't really blame on GNOME.

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 21, 2013

Contributor

I see this happening in vim too:

In file included from /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:194:0,
                 from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13,
                 from os_macosx.m:24:
/System/Library/Frameworks/AppKit.framework/Headers/NSWindowRestoration.h:119:116: error: expected ')' before '^' token
 - (void)restoreDocumentWindowWithIdentifier:(NSString *)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow *, NSError *))completionHandler NS_AVAILABLE_MAC(10_7);

      ^
/System/Library/Frameworks/AppKit.framework/Headers/NSWindowRestoration.h:119:118: error: expected ')' before '(' token
 - (void)restoreDocumentWindowWithIdentifier:(NSString *)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow *, NSError *))completionHandler NS_AVAILABLE_MAC(10_7);

        ^
gcc-4.8 -c -I. -Iproto -DHAVE_CONFIG_H   -F/usr/local/Frameworks -DMACOS_X_UNIX  -Os -w -pipe -march=core2 -msse4.1 -mmacosx-version-min=10.7 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       -o objects/main.o main.c
make[1]: *** [objects/os_macosx.o] Error 1

Maybe it doesn't like the NS_AVAILABLE_MAC macros?

(vim compiled fine on 10.4, including the ObjC parts.)

Contributor

mistydemeo commented Oct 21, 2013

I see this happening in vim too:

In file included from /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:194:0,
                 from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13,
                 from os_macosx.m:24:
/System/Library/Frameworks/AppKit.framework/Headers/NSWindowRestoration.h:119:116: error: expected ')' before '^' token
 - (void)restoreDocumentWindowWithIdentifier:(NSString *)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow *, NSError *))completionHandler NS_AVAILABLE_MAC(10_7);

      ^
/System/Library/Frameworks/AppKit.framework/Headers/NSWindowRestoration.h:119:118: error: expected ')' before '(' token
 - (void)restoreDocumentWindowWithIdentifier:(NSString *)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow *, NSError *))completionHandler NS_AVAILABLE_MAC(10_7);

        ^
gcc-4.8 -c -I. -Iproto -DHAVE_CONFIG_H   -F/usr/local/Frameworks -DMACOS_X_UNIX  -Os -w -pipe -march=core2 -msse4.1 -mmacosx-version-min=10.7 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       -o objects/main.o main.c
make[1]: *** [objects/os_macosx.o] Error 1

Maybe it doesn't like the NS_AVAILABLE_MAC macros?

(vim compiled fine on 10.4, including the ObjC parts.)

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 22, 2013

Contributor

glib also works fine on 10.4.

Contributor

mistydemeo commented Oct 22, 2013

glib also works fine on 10.4.

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Oct 22, 2013

Contributor

Since this fixed something, and doesn't break anything, I went ahead and integrated the fix upstream suggested.

Contributor

mistydemeo commented Oct 22, 2013

Since this fixed something, and doesn't break anything, I went ahead and integrated the fix upstream suggested.

@Homebrew Homebrew locked and limited conversation to collaborators Feb 17, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.