Bug 253014
| Summary: | net-im/telegram-desktop: Fails to build when devel/abseil is present on the system | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | olexander.v.melnyk | ||||||
| Component: | Individual Port(s) | Assignee: | Dmitry Marakasov <amdmi3> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | danfe, henry.hu.sh, olexander.v.melnyk | ||||||
| Priority: | --- | Flags: | henry.hu.sh:
maintainer-feedback+
|
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Okay, this is the ugly problem of "2 versions of libraries". In tg_owt's source code, there's a version of absl library. On the other hand, you have another version installed into the system. When compiling the code, it found the headers installed by the system version (which carries the absl::lts_2020_09_23 namespace). When linking, it instead linked with the object file compiled with the version in tg_owt's source code. It carries another namespace (just absl). Thus, the linking fails. The ideal solution is make the tg_owt library (inside telegram-desktop) try to use the headers in its source tree, instead of the system one. This might be hard, as the order is determined by command line flags, which typically includes /usr/local/include fairly early. Meanwhile, you have some options: 1. Temporarily remove abseil pkg, build it, then install it back. 2. Build the package using poudriere / in a jail. Current command line is: [1/2] /usr/local/libexec/ccache/c++ -DHAVE_NETINET_IN_H -DHAVE_WEBRTC_VIDEO -DRTC_ENABLE_VP9 -DWEBRTC_APM_DEBUG_DUMP=0 -DWEBRTC_ENABLE_LINUX_ALSA -DWEBRTC_ENABLE_LINUX_PULSE -DWEBRTC_ENABLE_PROTOBUF=0 -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -DWEBRTC_LIBRARY_IMPL -DWEBRTC_LINUX -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=1 -DWEBRTC_OPUS_VARIABLE_COMPLEXITY=0 -DWEBRTC_POSIX -DWEBRTC_USE_BUILTIN_ISAC_FLOAT -DWEBRTC_USE_H264 -I/usr/local/include -I/usr/local/include/opus -I../../src -I../../src/third_party/abseil-cpp -I../../src/third_party/libyuv/include -I../../src/third_party/pffft/src -I../../src/third_party/libsrtp/include -I../../src/third_party/libsrtp/crypto/include -I../../src/third_party/libvpx/source/libvpx -I../../src/third_party/libvpx/source/config -I../../src/third_party/libvpx/source/config/linux/x64 -O2 -pipe -march=native -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=native -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -Wno-deprecated-declarations -Wno-attributes -Wno-narrowing -Wno-return-type -std=gnu++17 -MD -MT CMakeFiles/tg_owt.dir/src/api/audio_codecs/audio_format.cc.o -MF CMakeFiles/tg_owt.dir/src/api/audio_codecs/audio_format.cc.o.d -o CMakeFiles/tg_owt.dir/src/api/audio_codecs/audio_format.cc.o -c ../../src/api/audio_codecs/audio_format.cc so -I/usr/local/include is the first, and -I../../src/third_party/abseil-cpp is the fourth. If we can move -I/usr/local/include after the other, the problem can be solved. Created attachment 221954 [details]
test path to prefer local libabsl
Please try the attached patch. This is a small hack to prefer local libabsl.
I think that this might be an issue for Linux users also. Maybe you can report it upstream too.
(In reply to Henry Hu from comment #3) At least it works for me, when abseil is installed. (In reply to Henry Hu from comment #3) With that patch all made without errors, thanks! Would someone please commit the patch? It is confirmed to fix this issue. I can't reproduce the original problem, it builds fine in presence of abseil. Is the fix still needed? This was resolved when I updated the port to 2.5.8. The patch was integrated. Good, closing then. |
Created attachment 221927 [details] A log of an unsuccessful building process FreeBSD version: 12.2-RELEASE-p1 GENERIC amd64 devel/abseil version: latest