Open peternewman opened 1 year ago
I'm trying to build this and I'm getting issue ~~#1867~~ #1864 .
Does anyone know a way around that issue here? I don't want to cross compile, just x86_64. I use this arch pkgbuild and change it's source to this branch.
Originally posted by @topas-rec in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1631477421
> I'm trying to build this and I'm getting issue ~#1867~ #1864 .
Can you share your config.log please?
Alternatively have a look here for something else to test that might help...: https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631629938
Originally posted by @peternewman in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1631656384
> Can you share your config.log please?
Sure
Alternatively have a look here for something else to test that might help...: https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631629938
I'll try that when I'm back at that machine. Thanks.
Originally posted by @topas-rec in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1631931543
> > Can you share your config.log please?
Sure ola-git configuration log
That's not quite what I'm looking for unfortunately. When it runs ./configure within that process, that should generate a file called config.log with a more verbose view of the configuration stage (and the failure).
I'll try that when I'm back at that machine. Thanks.
Thanks.
Originally posted by @peternewman in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1632245126
[config.log](https://github.com/OpenLightingProject/ola/files/12031126/config.log)
I cannot put this in here as text and even pastebin doesn't accept that size.
Most likely this is the problem: error: static assertion failed: Protobuf only supports C++14 and newer.
Originally posted by @topas-rec in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1633021183
>Alternatively have a look here for something else to test that might help...:
https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631629938
I picked the two commits with the version check into my C14 branch and added --with-protoc=/usr/bin/protoc
(from https://github.com/OpenLightingProject/ola/issues/1864#issue-1762515033) to the build command and I get this far in configuration:
[...]
checking for python extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages
checking for python module: google.protobuf... yes
checking for flake8... no
checking for libprotobuf... yes
set protoc to /usr/bin/protoc
checking protoc version... 23.4.0
checking for google/protobuf/compiler/command_line_interface.h... no
configure: error: Cannot find the protoc header files
Originally posted by @topas-rec in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1633083063
> I picked the two commits with the version check into [my C14 branch](https://github.com/topas-rec/ola/tree/0.10-c14-compat)
That looks fine.
and added
--with-protoc=/usr/bin/protoc
(from #1864 (comment)) to the build command
You don't need that bit unless you're trying to cross-compile, which I suspect you aren't.
and I get this far in configuration:
[...] checking for python extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages checking for python module: google.protobuf... yes checking for flake8... no checking for libprotobuf... yes set protoc to /usr/bin/protoc checking protoc version... 23.4.0 checking for google/protobuf/compiler/command_line_interface.h... no configure: error: Cannot find the protoc header files
Again this doesn't tell us enough and we need the config.log which will have a more informative error like you found above, but also some key info in the lines above the error, like did my gnu++11 flagging get correctly through to that code...
Originally posted by @peternewman in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1633274565
This is the config.log from my c14 branch mentioned above:
Originally posted by @topas-rec in https://github.com/OpenLightingProject/ola/issues/1875#issuecomment-1633557951
So @topas-rec the underlying error in those seems to be:
configure:25981: checking for google/protobuf/compiler/command_line_interface.h
configure:25981: g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -std=gnu++14 conftest.cpp >&5
In file included from /usr/include/absl/types/optional.h:39,
from /usr/include/absl/container/internal/common.h:22,
from /usr/include/absl/container/internal/btree.h:63,
from /usr/include/absl/container/btree_map.h:56,
from /usr/include/google/protobuf/compiler/command_line_interface.h:48,
from conftest.cpp:178:
/usr/include/absl/utility/utility.h:164:12: error: 'in_place_t' has not been declared in 'std'
164 | using std::in_place_t;
| ^~~~~~~~~~
This tells us that std::in_place_t is only since C++17 https://en.cppreference.com/w/cpp/utility/in_place
Which I think is down to the slightly daft live at head nonsense from the absl library. Which "version"/LTS of abseil are you using, or is it just pulling down the git head each time?
If you try and change all the 14s to 17s in the branch I pointed to or your clone, does that allow it to build, and if so do all the tests still pass? I fear unfortunately it's going to fail and you'll be stuck, becuase we're still using auto_ptr which is removed in C++17: https://en.cppreference.com/w/cpp/memory/auto_ptr
I think that's going to be a 0.12 release feature for us I'd imagine (with 500+ of them in the codebase), so you might have to live with a slightly older abseil for now if you want to build OLA, but as always PRs welcome!
Thanks for your help so far.
If you try and change all the 14s to 17s in the branch I pointed to or your clone, does that allow it to build
Sadly (but obviously) this is not enough. (There are many 14s in that code and comments. I replaced all ++14
with ++17
only. Occurrances were found only in configure.ac
.
I'll check if I can downgrade abseil (I use abseil-cpp 20230125.3-1
currently.
Thanks for your help so far.
No worries, thanks for reporting the error, it would get to the more stable releases in due course.
If you try and change all the 14s to 17s in the branch I pointed to or your clone, does that allow it to build
Sadly (but obviously) this is not enough. (There are many 14s in that code and comments. I replaced all
++14
with++17
only. Occurrances were found only inconfigure.ac
. config.log
Erm configure succeeded in that config.log, what's the error you actually had with building with that change in place?
I'll check if I can downgrade abseil (I use
abseil-cpp 20230125.3-1
currently.
Cool, hopefully that might be an option in the interim.
Yeah, the build started. Output was:
I didn't look into it, because I can imagine how much there is to do and I guess that exceeds my time for that. Maybe I will try that some day.
I'll check if I can downgrade abseil (I use
abseil-cpp 20230125.3-1
currently.Cool, hopefully that might be an option in the interim.
For everyone on arch:
warning: downgrading package protobuf (23.4-1 => 21.12-2)
makes ola-git run again.
For everyone on arch:
warning: downgrading package protobuf (23.4-1 => 21.12-2)
makes ola-git run again.
Excellent, I'm glad you've got an interim solution sorted.
Hopefully it's already obvious to arch users, but would you mind sharing the command to run to downgrade protobuf for the future selves who find themselves at this issue?
Yeah, the build started.
Well that's progress at least! :smile:
So there are three core classes of issue in that so far:
./protoc/ServiceGenerator.h:117:3: error: ISO C++ forbids declaration of ‘GOOGLE_DISALLOW_EVIL_CONSTRUCTORS’ with no type [-fpermissive]
117 | GOOGLE_DISALLOW_EVIL_CONSTRUCTORS(ServiceGenerator);
This seems to be fixed by dropping the old macro and replacing it with some delete commands: From: https://github.com/protocolbuffers/protobuf/pull/5368/files#diff-9ed8738d1449f4760c3f4865d147678a024a6d73d35ed94999db2d74b4bfa2edL65-L66
protoc/StrUtil.cpp: In function ‘char* ola::FastHexToBuffer(int, char*)’:
protoc/StrUtil.cpp:271:3: error: ‘GOOGLE_CHECK’ was not declared in this scope
271 | GOOGLE_CHECK(i >= 0)
This are just doing some compilation checks, so you could just delete/comment them out as a test.
protoc/StrUtil.cpp: In function ‘char* ola::FastUInt64ToBufferLeft(uint64_t, char*)’:
protoc/StrUtil.cpp:451:3: error: ‘GOOGLE_DCHECK_LT’ was not declared in this scope
451 | GOOGLE_DCHECK_LT(digits, 100);
Likewise again.
That ought to prove fairly quickly whether it will just work after that, or there will be a never ending list of further issues.
I'll also flag again, if someone either wants to volunteer a machine for us to test with via Buildbot, or better yet an Arch docker image or something we can run continuous integration against, we'd hopefully catch these issues sooner and maybe even before you notice as an end user...
My command is not everyone elses command because it depends on the installed packages (and arch users should know where to find such information ;-)).
One has to downgrade all packages that have unmet dependencies if protobuf
would be downgraded until the transaction is valid for pacman.
The arch wiki: Downgrading packages holds all necessary information about this. Including warnings, that partially upgrades are not supported. So this should be a temporary solution. A better temporary solution would be to create a compat package (from the arch FAQ).
Start with sudo pacman --upgrade /var/cache/pacman/pkg/protobuf-21.12-2-x86_64.pkg.tar.zst
(use packages from the cache on the hard drive or from the arch linux archive - see link to arch wiki: Downgrading packages above)
Then read the problems that pacman prints about packages that would have unmet dependencies if protobuf
would be downgraded.
Then downgrade those packages, too.
My specific command was sudo pacman --upgrade /var/cache/pacman/pkg/protobuf-21.12-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/libphonenumber-1:8.13.14-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/mumble-1.5.517-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/mumble-server-1.5.517-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/python-protobuf-21.12-2-x86_64.pkg.tar.zst
Then pacman
needs to ignore those packages on updates (see wiki link).
For everyone on arch:
warning: downgrading package protobuf (23.4-1 => 21.12-2)
makes ola-git run again.
This (holding back protobuf
and the dependencies listed above) doesn't work for me anymore. Other tools (Evolution in this case) need the updated libs.
I derived a "compat" package (see above) from the protobuf
PKGBUILD
. It provides just the missing protobufc.so.32
library. This works for me and is the better temporary solution.
I'll try to get this package into the AUR and link it here.
compat package for arch created at: https://aur.archlinux.org/packages/libprotobuf-compat-32
@topas-rec did you also manage to build ola on Arch? I believe for that we'll also need an older abseil-cpp
.
Update: legacy protobuf + abseil versions + fixed ola are now in proaudio + AUR.
The current Yocto version if failing due to the version of protoc is now 23.4.0
In the previous release of Yocto (Mickeldore) is was 3.21.12.
Is there already a solution (at branch or patch) for the fix of the checking for google/protobuf/compiler/command_line_interface.h... no
issue?
| checking for libprotobuf... yes
| set protoc to /home/jan/projects/meta-dmx512/build/tmp/work/x86_64-linux/ola-native/0.10.9/recipe-sysroot-native/usr/bin/protoc
| checking protoc version... 23.4.0
| checking for google/protobuf/compiler/command_line_interface.h... no
| configure: error: Cannot find the protoc header files
| NOTE: The following config.log files may provide further information.
| NOTE: /home/jan/projects/meta-dmx512/build/tmp/work/x86_64-linux/ola-native/0.10.9/ola-0.10.9/config.log
| ERROR: configure failed
The patch Fix protoc version checking, since v20.x did help to detect the protoc.
br
In the Gentoo Linux world, it's not yet a problem for stable amd64 systems (since other packages suffer the same pain as we do, see tracker bug at https://bugs.gentoo.org/912819). However, for unstable ~amd64 systems, protobuf might already be at 23.3. Ola's reference to the TRACKER bug is https://bugs.gentoo.org/923757
(This is after applying the fix for the protobuf version check in #1875.)
Originally posted by @SpotlightKid in https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1630487399
https://protobuf.dev/news/2022-08-03/ Likewise this release of Abseil should work with C++11: https://github.com/abseil/abseil-cpp/tree/20220623.1
Originally posted by @peternewman in https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631621302
Originally posted by @SpotlightKid in https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631625825
https://github.com/peternewman/ola/tree/0.10-c14-compat
More generally if someone can either do us a GitHub Action which compiles against Arch or can run a Buildbot or something we should catch these issues a lot sooner and be able to react to them better. Otherwise it's likely to be a case of pull requests welcome unfortunately...
Originally posted by @peternewman in https://github.com/OpenLightingProject/ola/issues/1867#issuecomment-1631629938