PARSER error: enum tag redefined

[darmie]

I am getting an error with parsing enums

$ go-kinc % c-for-go -ccincl -ccdefs kinc.yml
  processing kinc.yml ⠋[WARN] `cpp -dM` failed: exit status 1
  processing kinc.yml ⠸Sources/kinc/image.h:11:14: enum tag redefined, previous definition: Sources/kinc/image.h:11:9
Sources/kinc/image.h:18:14: enum tag redefined, previous definition: Sources/kinc/image.h:18:9
Sources/kinc/image.h:11:14: enum tag redefined, previous definition: Sources/kinc/image.h:11:9
Sources/kinc/image.h:18:14: enum tag redefined, previous definition: Sources/kinc/image.h:18:9
Sources/kinc/image.h:11:14: enum tag redefined, previous definition: Sources/kinc/image.h:11:9
Sources/kinc/image.h:18:14: enum tag redefined, previous definition: Sources/kinc/image.h:18:9
Sources/kinc/image.h:11:14: enum tag redefined, previous definition: Sources/kinc/image.h:11:9
Sources/kinc/image.h:18:14: enum tag redefined, previous definition: Sources/kinc/image.h:18:9
Sources/kinc/image.h:11:14: enum tag redefined, previous definition: Sources/kinc/image.h:11:9
Sources/kinc/image.h:18:14: enum tag redefined, previous definition: Sources/kinc/image.h:18:9
too many errors

image.h

#pragma once

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

#ifdef __cplusplus
extern "C" {
#endif

typedef enum kinc_image_compression {
    KINC_IMAGE_COMPRESSION_NONE,
    KINC_IMAGE_COMPRESSION_DXT5,
    KINC_IMAGE_COMPRESSION_ASTC,
    KINC_IMAGE_COMPRESSION_PVRTC
} kinc_image_compression_t;

typedef enum kinc_image_format {
    KINC_IMAGE_FORMAT_RGBA32,
    KINC_IMAGE_FORMAT_GREY8,
    KINC_IMAGE_FORMAT_RGB24,
    KINC_IMAGE_FORMAT_RGBA128,
    KINC_IMAGE_FORMAT_RGBA64,
    KINC_IMAGE_FORMAT_A32,
    KINC_IMAGE_FORMAT_BGRA32,
    KINC_IMAGE_FORMAT_A16
} kinc_image_format_t;

typedef struct kinc_image {
    int width, height, depth;
    kinc_image_format_t format;
    unsigned internal_format;
    kinc_image_compression_t compression;
    void *data;
    int data_size;
} kinc_image_t;

size_t kinc_image_init(kinc_image_t *image, void *memory, int width, int height, kinc_image_format_t format);
size_t kinc_image_init3d(kinc_image_t *image, void *memory, int width, int height, int depth, kinc_image_format_t format);
size_t kinc_image_init_from_file(kinc_image_t *image, void *memory, const char *filename);
void kinc_image_init_from_bytes(kinc_image_t *image, void *data, int width, int height, kinc_image_format_t format);
void kinc_image_init_from_bytes3d(kinc_image_t *image, void *data, int width, int height, int depth, kinc_image_format_t format);
void kinc_image_destroy(kinc_image_t *image);
int kinc_image_at(kinc_image_t *image, int x, int y);
uint8_t *kinc_image_get_pixels(kinc_image_t *image);

int kinc_image_format_sizeof(kinc_image_format_t format);

#ifdef __cplusplus
}
#endif

config

PARSER:
  IncludePaths: ["/usr/include", "/usr/local/include", "/usr/local/cellar", "Sources", "Backends/Graphics4/OpenGL/Sources","Backends/Graphics5/G5onG4/Sources", "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include"]
  SourcesPaths: ["kinc/window.h", "kinc/display.h", "kinc/color.h", "kinc/image.h", "kinc/system.h", "kinc/graphics4/graphics.h", "kinc/graphics5/graphics.h", "kinc/graphics1/graphics.h", "kinc/math/matrix.h", "kinc/math/random.h", "kinc/math/vector.h"]
  Defines: 
    KINC_FUNC: {}
TRANSLATOR: 
  ConstCharIsString: true
  ConstUCharIsString: false
  ConstRules: 
    defines: expand
    enum: eval
  Rules: 
    global: 
      - {transform: lower}
      - {action: accept, from: "^kinc_"}

[xlab]

I see that the header doesn't have pragma once, are you sure it's not being included multiple times?

Btw, a full source archive would be appreciated. :)

[darmie]

@xlab it has pragma once

kinc source is available at link

[darmie]

@xlab I see that the problem is because image.h is included in many places... How do I solve this problem? Project I am working with is not a single header library

[xlab]

Like I've guessed, there is nothing wrong with that particular header. It must be the includes list that have some names collision after joining all the sources together.

Look at this example:

kinc-go.zip

I took image.h and put simple manifest and generated using c-for-go -ccdefs kinc.yml on macOS. You can add more headers there.

[xlab]

@darmie normally, since header has pragma once, it won't be included in c-for-go processing multiple times. Start by including headers and see when it fails. I am not implying this should be just one header file :)

Btw, it's nothing wrong with creating a single header that will include all other headers in correct order. And then bind against that meta-header file. Just as a backup plan.

[darmie]

@xlab Ok I think a single header should work.

[darmie]

@xlab I finally generated bindings and wrote a wrapper for the project...

Another unrelated issue I am facing is undefined symbols error

ndefined symbols for architecture x86_64:
  "_kinc_abs", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_abs in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_abs)
  "_kinc_acceleration_callback", referenced from:
      _input_initializer in _x001.o
      _input_initializer in _x004.o
      __cgo_42aa6d8d395a_Cfunc_input_initializer in _x004.o
  "_kinc_acos", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_acos in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_acos)
  "_kinc_application_name", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_application_name in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_application_name)
  "_kinc_asin", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_asin in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_asin)
  "_kinc_atan", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_atan in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_atan2, __cgo_42aa6d8d395a_Cfunc_kinc_atan )
  "_kinc_atan2", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_atan2 in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_atan2)
  "_kinc_automatic_safe_zone", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_automatic_safe_zone in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_automatic_safe_zone)
  "_kinc_ceil", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_ceil in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_ceil)
  "_kinc_clamp", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_clamp in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_clamp)
  "_kinc_color_components", referenced from:
      __cgo_42aa6d8d395a_Cfunc_kinc_color_components in _x005.o
     (maybe you meant: __cgo_42aa6d8d395a_Cfunc_kinc_color_components)
  "_kinc_compute", referenced from:

What am I doing wrong?

[xlab]

@darmie means you're not linking against the C shared/static libs with the implementation.

Add in some non-generated file:

/*
#cgo LDFLAGS: -lkinc
*/
import "C"

Or specify using pkg-config:

https://github.com/xlab/c-for-go/wiki/Generator-config-section#pkgconfigopts

[darmie]

That is awkward. Kind doesn't compile as a shared library, plus all its dependencies are linked. Could it be a go package directory problem? Is the go compiler expecting the C files to be in the same directory as the go source files?

On Sun, 15 Nov 2020, 22:06 Max Kupriianov, notifications@github.com wrote:

@darmie https://github.com/darmie means you're not linking against the C shared/static libs with the implementation.

Add in some non-generated file:

/*

cgo LDFLAGS: -lkinc

*/ import "C"

Or specify using pkg-config:

https://github.com/xlab/c-for-go/wiki/Generator-config-section#pkgconfigopts

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xlab/c-for-go/issues/102#issuecomment-727636789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGPBASDLS77JKVBR7HDXOTSQA7FZANCNFSM4TVOU2MA .

[xlab]

Kind doesn't compile as a shared library

Then you should have a reference to static library.

go compiler expecting the C files to be in the same directory

If there is no shared or static linking, then yes. But this is not suitable for any large project, also C projects usually have tons of platform dependencies that are better to leave to make rather than figuring them out manually.