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

Failed build against newer libmicrohttpd versions #64

Open
hadret opened this issue Oct 8, 2021 · 1 comment
Open

Failed build against newer libmicrohttpd versions #64

hadret opened this issue Oct 8, 2021 · 1 comment

Comments

@hadret
Copy link

hadret commented Oct 8, 2021

When trying to compile against newer libmicrohttpd versions it fails with the following errror:

[ 95%] Building C object promhttp/CMakeFiles/promhttp.dir/src/promhttp.c.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/promhttp && /usr/bin/cc -Dpromhttp_EXPORTS -I/<<PKGBUILDDIR>>/promhttp/include -I/<<PKGBUILDDIR>>/
promhttp/../prom/include -I/<<PKGBUILDDIR>>/promhttp/src -I/<<PKGBUILDDIR>>/prom/include -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Werror -Wuninitialized -Wall -Wno-unused-label -
std=gnu11 -std=gnu11 -MD -MT promhttp/CMakeFiles/promhttp.dir/src/promhttp.c.o -MF CMakeFiles/promhttp.dir/src/promhttp.c.o.d -o CMakeFiles
/promhttp.dir/src/promhttp.c.o -c /<<PKGBUILDDIR>>/promhttp/src/promhttp.c
/<<PKGBUILDDIR>>/promhttp/src/promhttp.c: In function ‘promhttp_start_daemon’:
/<<PKGBUILDDIR>>/promhttp/src/promhttp.c:64:54: error: passing argument 5 of ‘MHD_start_daemon’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   64 |   return MHD_start_daemon(flags, port, apc, apc_cls, &promhttp_handler, NULL, MHD_OPTION_END);
      |                                                      ^~~~~~~~~~~~~~~~~
      |                                                      |
      |                                                      int (*)(void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, size_t *, void **) {aka int (*)(void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, long unsigned int *, void **)}
In file included from /<<PKGBUILDDIR>>/promhttp/src/promhttp.c:19:
/usr/include/microhttpd.h:2480:45: note: expected ‘MHD_AccessHandlerCallback’ {aka ‘enum MHD_Result (*)(void *, struct MHD_Connection *, co
nst char *, const char *, const char *, const char *, long unsigned int *, void **)’} but argument is of type ‘int (*)(void *, struct MHD_C
onnection *, const char *, const char *, const char *, const char *, size_t *, void **)’ {aka ‘int (*)(void *, struct MHD_Connection *, con
st char *, const char *, const char *, const char *, long unsigned int *, void **)’}
 2480 |                   MHD_AccessHandlerCallback dh, void *dh_cls,
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~
cc1: all warnings being treated as errors
make[3]: *** [promhttp/CMakeFiles/promhttp.dir/build.make:79: promhttp/CMakeFiles/promhttp.dir/src/promhttp.c.o] Error 1
make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:145: promhttp/CMakeFiles/promhttp.dir/all] Error 2

Breaking change was introduced in libmicrohttpd back in April last year:

Introduce enum MHD_Result for #MHD_YES/#MHD_NO to avoid using 'int' so much.
Note that this change WILL cause compiler warnings until (most) MHD callbacks
in application code change their return type from 'int' to 'enum MHD_Result'.
That said, avoiding possible confusions of different enums is going to make
the code more robust in the future. For conditional compilation, test
for "MHD_VERSION >= 0x00097002". -CG

hadret pushed a commit to hadret/prometheus-client-c that referenced this issue Oct 8, 2021
@wferi
Copy link

wferi commented Apr 3, 2023

#72 is the same issue. I noticed this one later, so the pull request only references #72.

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

No branches or pull requests

2 participants