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)

Thanks, I've reported the problem to the developers. They're usually good about responding to stuff.

https://github.com/gphoto/libgphoto2/issues/761

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@…>

In b2eedf8f48600579e8299375c49071873a1747e3/macports-ports (master):

libgphoto2: fix build errors, via less-strict compilation options
See: #64427

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

https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/88423/steps/install-port/logs/stdio

https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/171105/steps/install-port/logs/stdio

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:

https://github.com/gphoto/libgphoto2/blob/4602672a02a4daeeeeb6ef80a1ee6db7c4ebd14c/libgphoto2_port/libgphoto2_port/compiletime-assert.h#L33

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: assignedclosed

In eaf4d8adaa6c03a920b1d7add769dd746194817d/macports-ports (master):

libgphoto2: handle missing static_assert macro

Fixes: #64427

Note: See TracTickets for help on using tickets.