Opened 3 years ago
Closed 2 years ago
#64427 closed defect (fixed)
libgphoto2: builds failing on some buildbots
Reported by: | mascguy (Christopher Nielsen) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | thomasrussellmurphy (Thomas Russell Murphy) | |
Port: | libgphoto2 |
Description (last modified by mascguy (Christopher Nielsen))
This port is still failing to build on some of our buildbots:
https://ports.macports.org/port/libgphoto2/builds/
I'm also seeing similar local build failures, on macOS 10.12 through 10.14.
The compilation error appears (?) to be related to source file pentax/js0n.c
:
libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -D_GPHOTO2_INTERNAL_CODE -DLOCALEDIR=\"/opt/local/share/locale\" -DCAMLIBS=\"/opt/local/lib/libgphoto2/2.5.28\" -I.. -I.. -I../libgphoto2_port -I/opt/local/include -Wno-unused -pipe -Os -arch x86_64 -Werror=unknown-warning-option -Wall -Wextra -Weverything -Wno-error=documentation-deprecated-sync -Wno-unused-parameter -DLIBGPHOTO2 -DPKTDATADIR=\"/\" -pipe -Os -arch x86_64 -Werror=unknown-warning-option -Wall -Wextra -Weverything -Wno-error=documentation-deprecated-sync -Wno-unused-parameter -MT pentax/la-js0n.lo -MD -MP -MF pentax/.deps/la-js0n.Tpo -c pentax/js0n.c -fno-common -DPIC -o pentax/.libs/la-js0n.o pentax/js0n.c:14:32: error: unknown warning group '-Woverride-init', ignored [-Werror,-Wunknown-warning-option]
Blacklisting Clang versions prior to 1001 fixes the issue locally, though that's not ideal.
The best approach might be to simply eliminate the use of compiler option -Werror=unknown-warning-option
. But I haven't had a chance to test that theory, and it's unclear whether that's the only issue.
Change History (13)
comment:1 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:2 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 3 years ago by thomasrussellmurphy (Thomas Russell Murphy)
Cc: | thomasrussellmurphy added |
---|
comment:4 Changed 3 years ago by thomasrussellmurphy (Thomas Russell Murphy)
I'm seeing this failure with the same js0n.c
line referenced on 10.14.6. If useful, I can provide a full log.
comment:5 Changed 3 years ago by mascguy (Christopher Nielsen)
I took a quick look at this port's configure.ac
, relative to the various compiler flags. And this comment block calls out a solution:
dnl -------------------------------------------------------------------- dnl The goals here are twofold: dnl dnl * Produce as many compiler warnings as possible to find dnl potential problems in our own code. dnl dnl * Make sure our API header files are as broadly compatible as dnl possible. dnl dnl We want our library and driver code to compile with the lowest dnl possible number of warnings, and the pedantic compilation tests to dnl compile with zero warnings (-Werror) so we do not limit the users dnl of our API in their use of compiler warnings. dnl dnl If, for some reason, you need to build without all these compiler dnl warnings, run the build while setting CFLAGS to an empty string: dnl dnl $ make all check CFLAGS= dnl --------------------------------------------------------------------
So one easy solution is to simply specify CFLAGS
to Make, during the build phase. Tested locally with the following one-line change, and this indeed fixes the issue:
build.args-append CFLAGS="${configure.cflags}"
Ryan, this fix - along with a comment block elaborating on all of the above - is ready for commit. Do you mind if I go ahead and push that change, to fix this port? Or would you prefer to take a different approach?
comment:6 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
I was hoping to use the fix suggested by the developers, but since they haven't suggested one yet, sure, you can commit that workaround, but you'll also have to add [get_canonical_archflags cc]
.
comment:7 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:8 Changed 3 years ago by mascguy (Christopher Nielsen)
It looks like we still have some issues on older macOS releases, due to link-time failures:
Undefined symbols for architecture x86_64: "_static_assert", referenced from: _ptp_init_container in la-ptp.o ld: symbol(s) not found for architecture x86_64
comment:9 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
See https://github.com/Cyan4973/xxHash/issues/671 for how that problem was solved in another software package. (They rewrote it not to use _static_assert
). This problem should be reported to the developers of libgphoto2 so they can resolve it.
comment:10 Changed 3 years ago by kencu (Ken)
In this case, I believe if you explicitly set the C standard to something less than C11 you should be OK, as the fallback path will be used:
here are some other options.
static_assert
is supposed to work with C11 code, but it does not work when building C code with newer clangs on older systems like the 10.6.8 system I have in front of me. It shows an implicit function definition that then fails to link, as above. I presume the function is missing in the system headers <assert.h
on these older systems, and if that pans out true, it might be able to be added to legacysupport perhaps.
_Static_assert
does work, so you could define that, eg:
#define static_assert _Static_assert
compiling with clang++-mp-11 does work to compile static_assert
even in C code, but clang-mp-11 does not work. I presume it is in the newer c++ headers installed with clang++-mp-11.
We are likely to see this error more.
I don't believe there is anything wrong with libgphoto2, so you might get pushback from them about fixing it on their end.
comment:11 Changed 3 years ago by kencu (Ken)
Apple added the static_assert
definition to assert.h
to be used in c11 code at a certain point (exact point to be determined).
See the ends of:
https://opensource.apple.com/source/Libc/Libc-1439.40.11/include/assert.h.auto.html
https://opensource.apple.com/source/Libc/Libc-583/include/assert.h.auto.html
comment:12 Changed 3 years ago by mascguy (Christopher Nielsen)
Ryan, any thoughts relative to a preferred fix for these issues? (Ken provided some ideas, but not sure what the best approach is.)
comment:13 Changed 2 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Thanks, I've reported the problem to the developers. They're usually good about responding to stuff.
https://github.com/gphoto/libgphoto2/issues/761