GD_COLOR_MAP_X11 redeclared

[Former user]

Using libgd-gd-libgd-e432fcabd05b.tar.gz, compiling under mingw:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/opt//include -I/opt/include -IC:/MinGW/msys/1.0/opt/include/libpng16 -IC:/MinGW/msys/1.0/opt/include/freetype2 -IC:/MinGW/msys/1.0/opt/include -g -O2 -fvisibility=hidden -MT gd_color_map.lo -MD -MP -MF .deps/gd_color_map.Tpo -c gd_color_map.c  -DDLL_EXPORT -DPIC -o .libs/gd_color_map.o
gd_color_map.c:765:33: error: variable 'GD_COLOR_MAP_X11' definition is marked dllimport
 BGD_EXPORT_DATA_PROT gdColorMap GD_COLOR_MAP_X11 = {
                                 ^
gd_color_map.c:765:33: warning: 'GD_COLOR_MAP_X11' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]

Full make output attached.

[Pierre Joye]

Which version do you use? Preview release or master?

[Pierre Joye]

@vapier Do you have mingw at hand to fix it? I don't have a working version right now. Also be sure it does not break VC :)

If not, I can do it on Tomorrow or Thursday

[Mike Frysinger]

what is "VC" ? it's easy for me to generate mingw compilers under Gentoo.

[Pierre Joye]

Visual c++

[Mike Frysinger]

i don't really have any Windows installs let alone have VS/VC++ installed, so i can't make any claims there

[Pierre Joye]

ok, let fix it for mingw (cross compilation or on win, I will do the minw and vc windows part :)

[Mike Frysinger]

seems like we should revert 46f219617c964ddf93891ddf7efb71b010fa8c90

the warning that tried to fix was introduced by 4eb4e29e27c9ab19d3d139c9f756c0745b22587b

i'm not familiar with BGD_EXPORT_DATA_{PROT,IMPL}, but i don't think the ELF markings are doing what is intended by the defines

i think the best thing to do is rely on the fact that decls propagate attributes. that is, if you have a header that does:

__attribute__((visibility ("default"))) void foo(void);

your source C file does not need to also do that iff you include the header w/the prototype first.

#include "foo.h"
void foo(void) {
 ...
}

this works for GCC for sure (and has for a very long time -- i've always done things this way). i don't know about VC++.

[Pierre Joye]

We only want to expose the public APIs, and that's why we need to do that. Mark default private and explicitly declare other public.

On windows it has to be done as everything is private per default.

[Mike Frysinger]

right, but that's not what i'm referring to. doesn't matter ...

reading a bit more, we have very diff behavior when BGDWIN32 is involved:

#ifdef BGDWIN32
BGD_EXPORT_DATA_PROT dllimport
BGD_EXPORT_DATA_IMPL /* nothing */
#else
BGD_EXPORT_DATA_PROT dllexport
BGD_EXPORT_DATA_IMPL /* nothing */
#endif

but that never gets defined due to a typo in b4b3e60a2cbe169003d4d84839ec0cb56db13f22. the var in configure.ac should not have the ac_cv_ prefix.

once that gets fixed, we see that commit 173bd59082191f53780f333d9ac48843de35f64e added a logical error: we don't define BGDWIN32 to 1/0, we define/undefine it. so the src/gd.h code should be "#ifdef BGDWIN32" rather than "#if BGDWIN32".

once i fix those two things, mingw builds fine. these leaves me wondering though ... what's the point of BGDWIN32 ? maybe it's for VC++ builds ?

[Pierre Joye]

@vapier yes, mainly VC, not sure if mingw uses it too. And right, after re reading I realize I miss the part about only having the attributes in the header. I've to check the gcc doc :)

@oerdnj Can you take a look please?

[Former user]

Fix MinGW build (Courtesy of Mike Frysinger) (fixes #53)

→ <<cset 66501e2bc4e9>>