GNOME Bugzilla – Bug 770103
libcheck: fails to compile with mingw due to strsignal prototype mismatch
Last modified: 2016-09-26 10:02:09 UTC
Created attachment 333576 [details] [review] fix strsignla function prototype to match actual declaration strsignal prototype declares a return type of char* but implementation actually returns a const char*.
Comment on attachment 333576 [details] [review] fix strsignla function prototype to match actual declaration This reverts another commit: commit c9da8b0e7f53005ab125e48165dae39fbfee2352 Author: Anthony G. Basile <blueness@gentoo.org> Date: Sun Mar 13 11:05:29 2016 -0400 libcompat.h: strsignal() should be not be decleared const POSIX standards requires strsignal() to return a pointer to a char, not a const pointer to a char. [1] On uClibc, and possibly other libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares const char *strsignal (int sig) which causes a type error. [1] man 3 strsignal https://bugzilla.gnome.org/show_bug.cgi?id=763567
On which system does this fail to compile, which libc, version which?
With commit c9da8b0e, this builds on glibc, uclibc and musl. I've tested on those. If its failing on some other libc, we should look at whether or not they are POSIX compliant.
Compilation error happens with msys2 / mingw.
I chose to remove the const from the prototype. Would adding it to the method definition (as mentionned in https://bugzilla.gnome.org/show_bug.cgi?id=763567) work ?
(In reply to Philippe Renon from comment #5) > I chose to remove the const from the prototype. > Would adding it to the method definition (as mentionned in > https://bugzilla.gnome.org/show_bug.cgi?id=763567) work ? This is preferable and I should probably have done that in the original commit. Can you let us know if it works for mingw and I'll test your patch on the other libcs.
Created attachment 333981 [details] [review] fix strsignal function declaration to match prtotype
I replaced the previous patch with a new one that changes the method declaration. Compiles fine with mingw.
Any news ?
I'm confused. Just to confirm: - this works fine in master / 1.9.x, yes? - it needs fixing in the 1.8 branch - basically we just need to cherry-pick commit c9da8b0e7 into 1.8, no?
The issue affects branch 1.8 on msys2. Master seems fine. The link to the proposed cherry-pick leads nowhere.
https://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=c9da8b0e7
Yes, that commit does the same as the attached patch and needs to be cherry-picked in the 1.8 branch.
Ok, thanks for confirming. Fixed in 1.8 branch now as well.