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

Issue for building for Raspberry PI4 #249

Closed
paullee2018 opened this issue Apr 21, 2021 · 8 comments · Fixed by #250
Closed

Issue for building for Raspberry PI4 #249

paullee2018 opened this issue Apr 21, 2021 · 8 comments · Fixed by #250

Comments

@paullee2018
Copy link

hi,

I followed this tutorial to install the libepoxy.

https://www.raspberrypi.org/documentation/linux/software/libcamera/README.md

but I get the following error. It seems the header generated has khronos_uintptr_t declared twice. I deleted the last one and build/install works fine.

In file included from ../include/epoxy/gl.h:89, from ../src/dispatch_common.h:44, from ../src/dispatch_egl.c:28: include/epoxy/gl_generated.h:54:19: error: conflicting types for ‘khronos_uintptr_t’ typedef uintptr_t khronos_uintptr_t; ^~~~~~~~~~~~~~~~~ include/epoxy/gl_generated.h:42:32: note: previous declaration of ‘khronos_uintptr_t’ was here typedef unsigned long int khronos_uintptr_t; ^~~~~~~~~~~~~~~~~

Regards
Paul

@ebassi
Copy link
Collaborator

ebassi commented Apr 21, 2021

The generated files do not match these errors. The khronos_uintptr_t definition appears only once.

Have you tried building Epoxy multiple times? Care to try with:

git clean -xdf
meson setup _build .
meson compile -C _build
meson install -C _build

instead?

@paullee2018
Copy link
Author

paullee2018 commented Apr 27, 2021

meson install -C _build

Still complains when I run meson compile -C _build after running the first 2 commands

@ebassi
Copy link
Collaborator

ebassi commented Apr 27, 2021

Care to attach your include/epoxy/gl_generated.h to this issue?

@YuriSedunov
Copy link

This issue reproduced for all 32-bit architectures.

20 #pragma once
21 #include <inttypes.h>
22 #include <stddef.h>
23
24 #include "epoxy/common.h"
25 #define _khrplatform_h 1
26 typedef int8_t khronos_int8_t;
27 typedef int16_t khronos_int16_t;
28 typedef int32_t khronos_int32_t;
29 typedef int64_t khronos_int64_t;
30 typedef uint8_t khronos_uint8_t;
31 typedef uint16_t khronos_uint16_t;
32 typedef uint32_t khronos_uint32_t;
33 typedef uint64_t khronos_uint64_t;
34 typedef float khronos_float_t;
35 #ifdef _WIN64
36 typedef signed long long int khronos_intptr_t;
37 typedef unsigned long long int khronos_uintptr_t;
38 typedef signed long long int khronos_ssize_t;
39 typedef unsigned long long int khronos_usize_t;
40 #else
41 typedef signed long int khronos_intptr_t;
42 typedef unsigned long int khronos_uintptr_t;
43 typedef signed long int khronos_ssize_t;
44 typedef unsigned long int khronos_usize_t;
45 #endif
46 typedef uint64_t khronos_utime_nanoseconds_t;
47 typedef int64_t khronos_stime_nanoseconds_t;
48 #define KHRONOS_MAX_ENUM 0x7FFFFFFF
49 typedef enum {
50 KHRONOS_FALSE = 0,
51 KHRONOS_TRUE = 1,
52 KHRONOS_BOOLEAN_ENUM_FORCE_SIZE = KHRONOS_MAX_ENUM
53 } khronos_boolean_enum_t;
54 typedef uintptr_t khronos_uintptr_t;
55 typedef unsigned int GLenum;
56 typedef unsigned char GLboolean;
57 typedef unsigned int GLbitfield;
58 typedef void GLvoid;
59 typedef khronos_int8_t GLbyte;
60 typedef khronos_uint8_t GLubyte;

@ebassi
Copy link
Collaborator

ebassi commented Apr 30, 2021

Ah, yes, found it.

There's a redeclaration of khronos_uintptr_t because I missed the typedef below. On IA and 64 bit, and with GCC or C11, the redeclaration is allowed because the type is the same, so I couldn't see the build breaking locally or on the CI.

It would be nice to have a 32bit build to check this stuff.

I'll open a MR with a possible fix.

ebassi added a commit that referenced this issue Apr 30, 2021
The type is being redeclared because I didn't see the original
declaration when I wrote 144cbc9.

Fixes: #249
@ebassi
Copy link
Collaborator

ebassi commented Apr 30, 2021

@YuriSedunov @paullee2018 could you try the build with #250 applied?

@YuriSedunov
Copy link

Yes, build passed for all architectures.
http://git.altlinux.org/tasks/271008/

@ebassi
Copy link
Collaborator

ebassi commented Apr 30, 2021

Thanks!

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

Successfully merging a pull request may close this issue.

3 participants