Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac OS build issues #71

Open
charlesroelli opened this issue Aug 23, 2016 · 12 comments
Open

Mac OS build issues #71

charlesroelli opened this issue Aug 23, 2016 · 12 comments
Labels

Comments

@charlesroelli
Copy link

charlesroelli commented Aug 23, 2016

I am trying to compile the library on Mac OS X 10.6 (Snow Leopard). It uses a version of GCC that does not support typedef redefinitions [gcc version 4.2.1], so there is an error because of the typedefs in mypaint-glib-compat.h that are also present in glib's definitions. I have tried removing the doubled definitions from mypaint-glib-compat.h, and this did not work. Is there any way to build on Snow Leopard, using this version of GCC?

Here is the full make invocation and error:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/usr/local/include/json-c -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -D_POSIX_C_SOURCE=200809L -g -O2 -MT mypaint-surface.lo -MD -MP -MF .deps/mypaint-surface.Tpo -c mypaint-surface.c  -fno-common -DPIC -o .libs/mypaint-surface.o
In file included from /usr/local/include/glib-2.0/glib/gtypes.h:32,
                 from /usr/local/include/glib-2.0/glib/galloca.h:32,
                 from /usr/local/include/glib-2.0/glib.h:30,
                 from rng-double.h:7,
                 from helpers.h:4,
                 from mypaint-surface.c:24:
/usr/local/lib/glib-2.0/include/glibconfig.h:40: error: redefinition of typedef ‘guint16’
./mypaint-glib-compat.h:28: error: previous declaration of ‘guint16’ was here
In file included from /usr/local/include/glib-2.0/glib/galloca.h:32,
                 from /usr/local/include/glib-2.0/glib.h:30,
                 from rng-double.h:7,
                 from helpers.h:4,
                 from mypaint-surface.c:24:
/usr/local/include/glib-2.0/glib/gtypes.h:46: error: redefinition of typedef ‘gchar’
./mypaint-glib-compat.h:23: error: previous declaration of ‘gchar’ was here
/usr/local/include/glib-2.0/glib/gtypes.h:49: error: redefinition of typedef ‘gint’
./mypaint-glib-compat.h:24: error: previous declaration of ‘gint’ was here
/usr/local/include/glib-2.0/glib/gtypes.h:50: error: redefinition of typedef ‘gboolean’
./mypaint-glib-compat.h:25: error: previous declaration of ‘gboolean’ was here
/usr/local/include/glib-2.0/glib/gtypes.h:77: error: redefinition of typedef ‘gpointer’
./mypaint-glib-compat.h:20: error: previous declaration of ‘gpointer’ was here
@achadwick achadwick added the osx label Aug 26, 2016
@charlesroelli
Copy link
Author

I've realized after reading the source that the typedefs in 'mypaint-glib-compat.h' are only meant to be defined if 'G_LIB_H' is not defined. Even though I was building with 'glib' ('with-glib' in './configure'), 'G_LIB_H' was not defined for some reason. I got around the problem by removing all includes for the 'mypaint-glib-compat.h' file, and removing the 'G_BEGIN_DECLS' and 'G_END_DECLS'. I will look into why the 'glib' variable was not being defined.

@charlesroelli
Copy link
Author

So the 'glib.h' header file defines G_LIB_H, therefore it needs to be included before 'mypaint-glib-compat.h' is ever included, otherwise the types will be redefined, resulting in the error in my first post. I've now found the hacky way to do this: drop an "#include "glib.h"" in 'config.h', after configuring. This fixes the build for me without having to remove references to 'mypaint-glib-compat.h' as I tried previously. All the unit tests also run fine.

It seems that only some of the "mypaint-*.c" source files include the header file:
./mypaint-brush.c:26:#include "glib.h"
./mypaint-fixed-tiled-surface.c:10:#include "glib.h"
./mypaint-mapping.c:26:#include "glib.h"
(GitHub seemed to be removing the angular brackets from header files, so I replaced them with double-quotes for this comment)

Maybe they should all include it? Not really sure of the ramifications, but it seems logical.

@achadwick
Copy link
Member

@scallywag
Here's how to format text on github: https://guides.github.com/features/mastering-markdown/. I suggest you use

```
```

@achadwick
Copy link
Member

@scallywag
Did you mean __G_LIB_H__? That is the guard macro's name in my version of glib.h (2.50.2), not G_LIB_H. Note the absence of underscores.

What version of glib does your Snow Leopard box have?

@ryandesign
Copy link
Contributor

MacPorts user @barracuda156 reported this issue to us again today. libmypaint 1.6.1 doesn't build with Apple gcc 4.2.1 on Mac OS X 10.6.8:

In file included from /opt/local/include/glib-2.0/glib/gtypes.h:34,
                 from /opt/local/include/glib-2.0/glib/galloca.h:34,
                 from /opt/local/include/glib-2.0/glib.h:32,
                 from rng-double.h:7,
                 from helpers.h:5,
                 from mypaint-surface.c:24:
/opt/local/lib/glib-2.0/include/glibconfig.h:46: error: redefinition of typedef 'guint16'
mypaint-glib-compat.h:28: error: previous declaration of 'guint16' was here

It looks to me like the problem is:

  • mypaint-surface.c includes mypaint-surface.h
  • mypaint-surface.h includes mypaint-rectangle.h
  • mypaint-rectangle.h includes mypaint-glib-compat.h
  • mypaint-glib-compat.h checks if __G_LIB_H__ is defined. If it is, it does nothing, but it isn't, since glib.h hasn't been included yet, therefore it defines guint16 and other glib types

Then:

  • mypaint-surface.c includes helpers.h
  • helpers.h includes rng-double.h
  • rng-double.h checks if MYPAINT_CONFIG_USE_GLIB is true. If false, it would include mypaint-glib-compat.h, but since it is true, it includes glib.h, which includes other headers which want to define guint16 and other glib types but you've already defined them

It seems to me that the solution would be never to include mypaint-glib-compat.h if MYPAINT_CONFIG_USE_GLIB is true.

@barracuda156
Copy link

Perhaps unrelated, but it seems to fail on macOS 13 for some reason too: macports/macports-ports#19095 (comment)
Cannot check it locally, but on CI it does.

@ryandesign
Copy link
Contributor

Perhaps unrelated

Yes, that's unrelated.

This issue is only about type redefinition errors which happen on old compilers.

@barracuda156
Copy link

@ryandesign I have found now an old portfile which @kencu made for libmypaint to fix build on Leopard (Intel), and it just sets cxx_standard to 2011.

@ryandesign
Copy link
Contributor

As far as I know, that wouldn't be a correct fix because libmypaint doesn't contain any C++ code. It would have the effect of avoiding the use of gcc 4.2.1 (since g++ 4.2.1 doesn't support C++11) but this issue is about fixing the problem when using gcc 4.2.1.

@barracuda156
Copy link

@ryandesign I am sorry, it is of course compiler.c_standard 2011 in Ken’s portfile – referring to redefinition of typedef gchar. (I saw the year and didn’t pay attention to lang.)

@ryandesign
Copy link
Contributor

ryandesign commented Jun 16, 2023

Either way, specifying an inaccurate language requirement is not the fix I would hope for. The build log shows that -std=gnu99 is being used, so the authors of libmypaint appear to intend for it to be buildable with compilers supporting C99 with GNU extensions. gcc 4.2.1 meets that criteria. If you erroneously tell MacPorts that this software requires C11, then MacPorts will remove from consideration all compilers (including gcc 4.2.1) that don't support C11. This will fix the build failure in MacPorts because it will force MacPorts to use a newer compiler that isn't so picky about type redefinitions, but does not fix libmypaint so that it can build with those old picky compilers, which is hopefully what the resolution of this issue will be.

@barracuda156
Copy link

@ryandesign Yes, I get your point, and it makes good sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants