Hello I'm using bear for a project to be able to get clangd informations in Helix editor. I've tried this on FreeBSD 13.4-RELEASE-p1 and it's working clearly well. But on FreeBSD 14.1-RELEASEp-5, I'm getting some interesting error messages: ld-elf.so.1: /usr/local/lib/libgrpc.so.44: Undefined symbol "_ZN4absl12lts_202407224CordC1INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_" ld-elf.so.1: /usr/local/lib/libgrpc.so.44: Undefined symbol "_ZN4absl12lts_202407224CordC1INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_" make: "/usr/share/mk/bsd.compiler.mk" line 200: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status make: "/usr/share/mk/bsd.compiler.mk" line 204: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. I've tried reinstalling the packages, and also tried on another 14.1-RELEASE machine, both output the same. The command I'm using is: bear --force-wrapper --append -- make CC=cc -C srcdir is there something I'm not doing right?
Hello, Are you using the official packages? It looks like devel/bear didn't get a PORTREVISION bump after devel/grpc was updated in 2715f16944541b6b27d121a57133347574a51ff1. I submitted a review to the devel/grpc maintainer and author of that commit, so a new devel/bear package with a fix should be available soon. https://reviews.freebsd.org/D47513 Thanks for reporting.
(In reply to Joseph Mingrone from comment #1) I'm pretty sure to use the "latest" packages repository, here are the informations about the package locally: bear-3.1.5_2 Name : bear Version : 3.1.5_2 Installed on : Fri Nov 8 10:40:18 2024 CET Origin : devel/bear Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : devel Licenses : GPLv3+ Maintainer : jrm@FreeBSD.org WWW : https://github.com/rizsotto/Bear Comment : Tool that generates a compilation database for clang tooling Options : DOCS : on [Shared libs...] Annotations : FreeBSD_version: 1401000 build_timestamp: 2024-11-02T08:31:56+0000 built_by : poudriere-git-3.4.2 port_checkout_unclean: no port_git_hash : 94829e74ad ports_top_checkout_unclean: no ports_top_git_hash: 009a7c198e repo_type : binary repository : FreeBSD Flat size : 1.21MiB [Description...] I'm not using a private package repository.
Thanks for confirming. Once the fix in the review I shared lands and a package for bear-3.1.5_3 is available, your problem should be fixed.
(In reply to Joseph Mingrone from comment #3) Thank you
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b359e3699e7c0ceddf80d07c0855be02d689c34e commit b359e3699e7c0ceddf80d07c0855be02d689c34e Author: Joseph Mingrone <jrm@FreeBSD.org> AuthorDate: 2024-11-11 16:45:39 +0000 Commit: Joseph Mingrone <jrm@FreeBSD.org> CommitDate: 2024-11-12 03:13:54 +0000 Bump PORTREVISIONs after grpc shlib change in 2715f16944541b6b PR: 282624 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D47513 biology/ncbi-blast+/Makefile | 2 +- databases/arrow/Makefile | 2 +- devel/bear/Makefile | 2 +- devel/google-cloud-cpp/Makefile | 2 +- net-mgmt/fastnetmon/Makefile | 2 +- net/rubygem-grpc/Makefile | 1 + science/py-tensorflow/Makefile | 2 +- sysutils/syslog-ng/Makefile | 2 +- www/freenginx-devel/Makefile | 2 +- www/freenginx/Makefile | 2 +- www/nginx-devel/Makefile | 2 +- www/nginx/Makefile | 2 +- 12 files changed, 12 insertions(+), 11 deletions(-)
It looks like a package should be ready on 14.1 for bear-3.1.5_3. https://pkg-status.freebsd.org/beefy22/data/141amd64-default/latest-per-pkg/bear-3.1.4_3.log Could you confirm your problem is solved?
(In reply to Joseph Mingrone from comment #6) Sorry for the late answer, I just had the pkg upgrade to get the latest package version. It is still not working. But now I guess it may be more like a grpc package problem? ld-elf.so.1: /usr/local/lib/libgrpc.so.44: Undefined symbol "_ZN4absl12lts_202407224CordC1INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_" ld-elf.so.1: /usr/local/lib/libgrpc.so.44: Undefined symbol "_ZN4absl12lts_202407224CordC1INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_" make: "/usr/share/mk/bsd.compiler.mk" line 200: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status make: "/usr/share/mk/bsd.compiler.mk" line 204: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. > pkg info -o bear grpc bear-3.1.5_3 devel/bear grpc-1.67.1,2 devel/grpc
(In reply to Guillaume Bibaut from comment #7) After reading the Undefined Symbol string a few time, I happened to find that it was related with abseil package. So I've tried to get that package back from the package repository with: pkg install -F -f abseil pkg install -f abseil And it fixed my problem! I had tried some commands with pkg check, but it always returned no error. Sorry for the inconvenience!
Glad it's working for you, and thanks for reporting back. I think you're correct. It's a symbol in abseil that grpc isn't finding. $ readelf -a /usr/local/lib/libabsl_cord.so | grep EE5valueEiE4typeELi0EEEOSB 115: 000000000000d5d0 206 FUNC WEAK DEFAULT 14 _ZN4absl12lts_202407224CordC1INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_ 116: 000000000000d5d0 206 FUNC WEAK DEFAULT 14 _ZN4absl12lts_202407224CordC2INSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEETnNS3_9enable_ifIXsr3std7is_sameIT_S9_EE5valueEiE4typeELi0EEEOSB_ Abseil was last updated in early August in 6c2f347f45e45cd71bb0aa7fdcaa96667c5a483b, so I'm unsure why grpc, which was updated just over two weeks ago, did not find that symbol. Are you locking certain packages so they don't get updated? Are you using a method other than `pkg upgrade` to upgrade packages (like `pkg install -f <package>` or using multiple repositories)? If the answer to all these questions is 'no', then I'm stumped.
I currently do not have any packages related to grpc which could lock: root@fractal:~ # pkg unlock -a 7-zip-24.08: already unlocked root@fractal:~ # pkg info -d 7-zip 7-zip-24.08: libsysinfo-0.0.3_3 root@fractal:~ # pkg info -d libsysinfo libsysinfo-0.0.3_3: root@fractal:~ # I had a custom repo with defaults options (which should not break compat) to compile wine and wine-proton so version is sync'ed on both package, but that was 3 months ago and I've deactivated it a week after. My method to upgrade packages is: pkg update pkg upgrade pkg autoremove I'm sometime forcing install with pkg install -f, but not on a regular base.
I'll close this as "Overcome by Events". I can only guess that this isn't a general problem. Thanks again for sharing all the details and reporting back that things are working again.