Mac OS build issues about libmypaint

[ryandesign]

Perhaps unrelated

Yes, that's unrelated.

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

[ryandesign]

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.

[charlesroelli]

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]

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]

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

```
```

[achadwick]

@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]

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]

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.

[barracuda156]

@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]

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]

@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.)

[barracuda156]

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