Created attachment 745635 [details] emerge log New merge against (new) protobuf-3.17.3. USE flags for both: [ebuild R ] dev-libs/protobuf-3.17.3:0/28::gentoo USE="zlib -emacs -examples -static-libs -test" 0 KiB [ebuild N ] dev-libs/protobuf-c-1.4.0:0/1.0.0::gentoo USE="-static-libs -test" 0 KiB >>> Compiling source in /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 ... * abi_x86_64.amd64: running multilib-minimal_abi_src_compile make -j7 -l10 /usr/bin/protoc -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 --cpp_out=. /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c/protobuf-c.proto /usr/bin/protoc -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 --cpp_out=. /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c/protobuf-c.proto google/protobuf/descriptor.proto: File not found. protobuf-c/protobuf-c.proto:31:1: Import "google/protobuf/descriptor.proto" was not found or had errors. protobuf-c/protobuf-c.proto:60:8: "google.protobuf.FileOptions" is not defined. protobuf-c/protobuf-c.proto:75:8: "google.protobuf.MessageOptions" is not defined. protobuf-c/protobuf-c.proto:84:8: "google.protobuf.FieldOptions" is not defined. x86_64-pc-linux-gnu-g++ -std=c++11 -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 -include ./config.h -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c -I. -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 -pthread -march=native -O2 -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -fdiagnostics-color -c -o protoc-c/protoc_gen_c-c_bytes_field.o `test -f 'protoc-c/c_bytes_field.cc' || echo '/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/'`protoc-c/c_bytes_field.cc google/protobuf/descriptor.proto: File not found. protobuf-c/protobuf-c.proto:31:1: Import "google/protobuf/descriptor.proto" was not found or had errors. protobuf-c/protobuf-c.proto:60:8: "google.protobuf.FileOptions" is not defined. protobuf-c/protobuf-c.proto:75:8: "google.protobuf.MessageOptions" is not defined. protobuf-c/protobuf-c.proto:84:8: "google.protobuf.FieldOptions" is not defined. make: *** [Makefile:2698: protobuf-c/protobuf-c.pb.cc] Error 1 make: *** Waiting for unfinished jobs.... make: *** [Makefile:2698: protobuf-c/protobuf-c.pb.h] Error 1 In file included from /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protoc-c/c_bytes_field.cc:64: /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protoc-c/c_helpers.h:70:10: fatal error: protobuf-c/protobuf-c.pb.h: No such file or directory 70 | #include <protobuf-c/protobuf-c.pb.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Attaching emerge log, emerge ---info to be attached.
Created attachment 745638 [details] emerge --info
Needed for sys-apps/fwupd-1.7.0's new USE=logitech (which I believe covers my logitech cordless keyboard and touchpad's usb adaptor).
With MAKEOPTS=-j1 it fails even faster: >>> Compiling source in /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 ... * abi_x86_64.amd64: running multilib-minimal_abi_src_compile make -j1 /usr/bin/protoc -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 --cpp_out=. /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c/protobuf-c.proto google/protobuf/descriptor.proto: File not found. protobuf-c/protobuf-c.proto:31:1: Import "google/protobuf/descriptor.proto" was not found or had errors. protobuf-c/protobuf-c.proto:60:8: "google.protobuf.FileOptions" is not defined. protobuf-c/protobuf-c.proto:75:8: "google.protobuf.MessageOptions" is not defined. protobuf-c/protobuf-c.proto:84:8: "google.protobuf.FieldOptions" is not defined. make: *** [Makefile:2698: protobuf-c/protobuf-c.pb.cc] Error 1
protobuf-c-1.3.3 merges fine.
Works for me. Note that the command /usr/bin/protoc -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 --cpp_out=. /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c/protobuf-c.proto said "google/protobuf/descriptor.proto: File not found." On my environment, /usr/include/google/protobuf/descriptor.proto has been installed with dev-libs/protobuf-3.17.3, and it can be found by the protoc command. FWIW, strace of the command has the following lines: access("/usr/bin/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT (No such file or directory) access("/usr/bin/include/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT (No such file or directory) access("/usr/include/google/protobuf/descriptor.proto", F_OK) = 0
Downgrading to dev-libs/protobuf-c-1.3.3-r1 (masking out dev-libs/protobuf-c-1.4.0-r1 temporarily) before emerging protobuf-c-1.4.0-r1 did the job for me.
(In reply to hangglider from comment #6) > Downgrading to dev-libs/protobuf-c-1.3.3-r1 (masking out > dev-libs/protobuf-c-1.4.0-r1 temporarily) before emerging > protobuf-c-1.4.0-r1 did the job for me. Would have been nice if it worked here, but with protobuf-3.17.3 and protobuf-c-1.3.3-r1 merged, I still get the same error trying to merge protobuf-c-1.4.0-r1. =:^( The good news, however, is that with a (not yet in-tree) fix for bug #818790 against fwupd with USE=logitech (that being what I needed protobuf-c for), I've tested it against protobuf-c-1.3.3-r1 and it works, so while I can't get 1.4.0 merged, I'm not out functionality until we can figure out and fix whatever's breaking 1.4.0 for me here.
(In reply to Tee KOBAYASHI from comment #5) > Note that the command > > /usr/bin/protoc > -I/tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0 --cpp_out=. > /tmp/portage/dev-libs/protobuf-c-1.4.0/work/protobuf-c-1.4.0/protobuf-c/ > protobuf-c.proto > > said "google/protobuf/descriptor.proto: File not found." > > On my environment, /usr/include/google/protobuf/descriptor.proto has been > installed with dev-libs/protobuf-3.17.3, and it can be found by the protoc > command. FWIW, strace of the command has the following lines: What exact command did you use? Simply "protoc" just prints a help message and stracing it doesn't yield anything useful. There's no manpage and not knowing what protoc is actually supposed to do the help "isn't helpful". (But see below.) > access("/usr/bin/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT (No > such file or directory) > access("/usr/bin/include/google/protobuf/descriptor.proto", F_OK) = -1 > ENOENT (No such file or directory) > access("/usr/include/google/protobuf/descriptor.proto", F_OK) = 0 But then I looked a bit closer at the log and saw where you were getting the protobuf command from, so I tried just copying it from the log. Tho of course I'm not in the same environment as the build, am executing as a different user, and I'm not sure I'm executing from the same dir which could matter as I see that "--cpp_out=." So I'm not entirely sure the strace results are reflective of what the build run would get. Never-the-less, from the build's amd64 abi subdir (additional newlines between lines added for clarity)... $ strace -efile /usr/bin/protoc -I/tmp/portage/dev-libs/protobuf-c-1.4.0-r1/work/protobuf-c-1.4.0 --cpp_out=. /tmp/portage/dev-libs/protobuf-c-1.4.0-r1/work/protobuf-c-1.4.0/protobuf-c/protobuf-c.proto 2>&1 | grep descript access("/bin/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT (No such file or directory) access("/bin/include/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/tmp/portage/dev-libs/protobuf-c-1.4.0-r1/work/protobuf-c-1.4.0/google/protobuf/descriptor.proto", 0x7fffbe8f1410, 0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/tmp/portage/dev-libs/protobuf-c-1.4.0-r1/work/protobuf-c-1.4.0/google/protobuf/descriptor.proto", O_RDONLY) = -1 ENOENT (No such file or directory) google/protobuf/descriptor.proto: File not found. protobuf-c/protobuf-c.proto:31:1: Import "google/protobuf/descriptor.proto" was not found or had errors. Two things to note: 1) Explaining the /bin (not /usr/bin), I have a "reverse usr-merge". That is, /usr is a symlink: /usr -> . , so /usr/bin is canonically /bin (and it picked up on that), /usr/lib64 is /lib64, /usr/include is /include ... but the /usr/* locations normally still work and portage installs to them actually install to / due to the /usr -> . symlink. 2) While I have parallels to your (/usr)/bin/ accesses with the expected -1 ENOENT results, I'm missing your (/usr)/include access, tho I can confirm the file is indeed there as it should be. (It then appears to check the package-building location and fails to find it there either, before giving up. I suppose your run didn't look there as it had found the file already.) Meanwhile, at least from the changelog, there weren't /that/ many commits between 1.3.3 which builds for me and 1.4.0 which doesn't. Maybe looking at the git commits will help. (Tho I'm not a dev, but sometimes I can spot things if they're obvious enough, often with some bisect help to narrow down the possibilities even further.)
(In reply to Duncan from comment #8) > $ strace -efile /usr/bin/protoc [...] > access("/bin/include/google/protobuf/descriptor.proto", F_OK) = -1 ENOENT > (No such file or directory) > Curious... > [snip] > > 1) Explaining the /bin (not /usr/bin), I have a "reverse usr-merge". That > is, /usr is a symlink: /usr -> . , so /usr/bin is canonically /bin (and it > picked up on that), /usr/lib64 is /lib64, /usr/include is /include ... but > the /usr/* locations normally still work and portage installs to them > actually install to / due to the /usr -> . symlink. > Oh you! I always forget about this. In future, add it at the bottom of your bug reports so we don't forget about that factor. >[snip] > > Meanwhile, at least from the changelog, there weren't /that/ many commits > between 1.3.3 which builds for me and 1.4.0 which doesn't. Maybe looking at > the git commits will help. (Tho I'm not a dev, but sometimes I can spot > things if they're obvious enough, often with some bisect help to narrow down > the possibilities even further.) A bisect would really help as I'm no protobuf expert. Will poke more at the rest of what you said if we don't get any further with that. Help welcome from anybody else who knows anything about protobuf-c too ;) Thanks for your debugging efforts as usual.
Upstream issue #491 is building with MS Visual Studio but the error appears to be the same and it suggests a CMakeLists.txt fix adding -I${PROTOBUF_INCLUDE_DIR} that I'm going to try creating a patch for... https://github.com/protobuf-c/protobuf-c/issues/491
(In reply to Duncan from comment #10) > suggests a CMakeLists.txt fix Unfortunately not so easy as gentoo's using the autotools builds, not cmake... But I noticed the upstream changelog had numbers that correspond to their PRs with a 1:1 correspondence, so I went thru all of them. Only one looks likely as a culprit: protoc-c: add custom options support https://github.com/protobuf-c/protobuf-c/pull/466 That's still 11 commits, but of the 11, one looked most interesting as it seems to add the plumbing the others use, /including/ the new protobuf-c.proto file that seems to be producing my errors: protoc-c: add custom options support https://github.com/protobuf-c/protobuf-c/pull/466/commits/0e060260f0d13f51c545b498a49701308f398c96 Interleaving that with the info from comment #10's issue #491, I'm thinking it's the makefile.am changes, specifically the new line (113 and) 114, that need the change. Untested but something like (pseudopatch, just using the cmake var from the issue, may be something else with autotools): - $(AM_V_GEN)@PROTOC@ -I$(top_srcdir) --cpp_out=$(top_builddir) $(top_srcdir)/protobuf-c/protobuf-c.proto + $(AM_V_GEN)@PROTOC@ -I$(PROTOBUF_INCLUDE_DIR) -I$(top_srcdir) --cpp_out=$(top_builddir) $(top_srcdir)/protobuf-c/protobuf-c.proto Looks like line 2633 may need similar. I guess eautoreconf... will finish the job once we patch those. Gotta be up in a couple hours so won't try it tonight, but with any luck this is most of the work anyway.
Created attachment 747018 [details, diff] feed protoc @includedir@ Signed-off-by: John Duncan This "works for me" (tm) Of course there were a few more things to patch up once I did the fix mentioned in the earlier comment, but once I had the idea down they were trivial as a global search&replace in Makefile.am. Feel free to submit this upstream if considered appropriate, as well.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=636a457ddfdef16faef6d374298123bc4cee5438 commit 636a457ddfdef16faef6d374298123bc4cee5438 Author: John Duncan <1i5t5.duncan@cox.net> AuthorDate: 2021-11-04 21:03:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-04 21:03:57 +0000 dev-libs/protobuf-c: fix include path Closes: https://bugs.gentoo.org/818775 Signed-off-by: John Duncan <1i5t5.duncan@cox.net> Signed-off-by: Sam James <sam@gentoo.org> .../files/protobuf-c-1.4.0-include-path.patch | 105 +++++++++++++++++++++ dev-libs/protobuf-c/protobuf-c-1.4.0-r1.ebuild | 4 + 2 files changed, 109 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b636acab6ea7ca7606ec9dbc00d57b6f9825b7e commit 5b636acab6ea7ca7606ec9dbc00d57b6f9825b7e Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-04 21:34:42 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-04 21:34:49 +0000 dev-libs/protobuf-c: flip include order Closes: https://bugs.gentoo.org/821727 Bug: https://bugs.gentoo.org/818775 Signed-off-by: Sam James <sam@gentoo.org> .../files/protobuf-c-1.4.0-include-path.patch | 26 +++++++++++----------- 1 file changed, 13 insertions(+), 13 deletions(-)
