v2.1.10
should run as v2.1.7
did
> ./Telegram
./Telegram: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./Telegram)
Operating system: CentOS Linux release 7.8.2003 (Core)
glibc version: glibc-2.17-307.el7.1.x86_64
Version of Telegram Desktop: 2.1.10
Installation source (Linux Only): automatic update, web page download and github release download lead to the same problem
I might be running into the same issue, also on 2.1.10
currently. It doesn't launch on my Arch Linux install anymore as well after the latest update, unless I run it with:
GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb telegram-desktop & disown
The above seems to somewhat mess with my copy and paste functionality, as I am on Wayland. In addition to that, I am also using Sway.
I tried the following versions and it fails to launch on 2.1.8:
Agreed, and glibc 2.17 is latest available from official CentOS 7 repo:
Installed Packages glibc.i686 2.17-307.el7.1 @base glibc.x86_64 2.17-307.el7.1 @base glibc-common.x86_64 2.17-307.el7.1 @base glibc-devel.x86_64 2.17-307.el7.1 @base glibc-headers.x86_64 2.17-307.el7.1 @base Available Packages glibc-devel.i686 2.17-307.el7.1 base glibc-static.i686 2.17-307.el7.1 base glibc-static.x86_64 2.17-307.el7.1 base glibc-utils.x86_64 2.17-307.el7.1 base
I might be running into the same issue, also on
2.1.10
currently. It doesn't launch on my Arch Linux install anymore as well after the latest update, unless I run it with:
No, it's due to activated deep-linking with QLibrary when loading gtk to not to crash when opening gtk dialog on wayland. But now tdesktop crashes if libwayland on your distro (1.18) is newer rather than compiled in the static binary (1.16) since gtk in your system uses new symbols in libwayland while they aren't present in tdesktop's libwayland
Thank you for the explanation, @ilya-fedin. Is the goal to upgrade the included version in the static binary in the near future? I'll run 2.1.7
for now.
Thank you for the explanation, @ilya-fedin. Is the goal to upgrade the included version in the static binary in the near future?
This is a question for @john-preston
Seems like Centos 7 didn't support GLIBC - 2.18. What should we do if the app would be deprecated after 1 September?
What should we do if the app would be deprecated after 1 September?
Update your OS
New minimal glibc version will be glibc 2.23 (Ubuntu 16.04)
Centos 7 is up to date but glibc is 2.17
CentOS 7 deprecated
CentOS 7 deprecated
CentOS 7 is supported unitl mid 2024 and CentOS/RHEL 7 is use in quite some companies and universities.
Would it not be an option to provide a fully static compiled binary or e.g. an AppImage for those distros that you do not support with native packages?
Would it not be an option to provide a fully static compiled binary
no
or e.g. an AppImage
AppImages rely on system glibc too.
that you do not support with native packages?
There are no official native packages, only snap and flatpak
@imjasonmiller The 2.1.11 version should run fine. After 2020 September 1 I'm afraid this old version of glibc won't be supported in the official binary build.
If enough users use it on the CentOS 7, they can find a maintainer who will build a version for their system. Or they can upgrade to CentOS 8, I hope it has a more modern version of glibc.
My problem is that currently I'm forced to build my versions on Ubuntu 14.04 which even can't run in my Parallels VM any more (new instance simply can't be set up, I run the old versions now that I set up while it still was supported). Moreover, even Ubuntu 14.04 has a higher version of glibc, so I have to pay a very close look on how the build is done and what are the dependencies, so that nothing calls any glibc 2.18 methods. Sometimes they do and I get a problem like this issue.
But now I need to migrate to Ubuntu 16.04 and there is no way to build a version that will launch fine on CentOS 7 (it's like Ubuntu 12.04), even the AppImage build from Ubuntu 16.04 won't work there. So here come the deprecations :(
Also perhaps Snap or Flatpak version could be used.
I just tried 2.1.11
@john-preston and it fails to start as well, while rolling back to 2.1.7
works. I could make a separate thread for this if it's a different issue.
I just tried
2.1.11
@john-preston and it fails to start as well
What error do you get?
It gives me the crash report below @ilya-fedin, with an associated dump.
ApiId: 2040
Binary: Telegram
Launched: 09.06.2020 19:07:11
Platform: Linux64bit
UserTag: $USERTAG
Version: 2001011
Caught signal 11 (SIGSEGV) in thread 140576686972288
Backtrace:
/opt/Telegram/Telegram[0x1929578]
/usr/lib/libpthread.so.0(+0x14960)[0x7fda8fe16960]
[0x1]
/opt/Telegram/Telegram(wl_list_remove+0x7)[0x2d0f6b7]
[0x1]
/opt/Telegram/Telegram(wl_list_remove+0x7)[0x2d0f6b7]
/opt/Telegram/Telegram[0x2d0b7f3]
/opt/Telegram/Telegram(wl_display_dispatch_queue_pending+0x74)[0x2d0cc54]
/usr/lib/libgdk-3.so.0(+0x6701e)[0x7fda5476601e]
/usr/lib/libgdk-3.so.0(gdk_display_manager_open_display+0x116)[0x7fda54794bf6]
/usr/lib/libgtk-3.so.0(gtk_init_check+0x24)[0x7fda782c3aa4]
/opt/Telegram/Telegram[0x13b2082]
/opt/Telegram/Telegram(_ZN8Platform4Libs5startEv+0x67)[0x13b22a7]
/opt/Telegram/Telegram(_ZN10ThirdParty5startEv+0xb)[0x18afc5b]
/opt/Telegram/Telegram(_ZN4Core11Application3runEv+0x1b)[0x1979adb]
/opt/Telegram/Telegram(_ZN4Core7Sandbox6notifyEP7QObjectP6QEvent+0xf5)[0x18b5475]
/opt/Telegram/Telegram[0x2ba5fd9]
/opt/Telegram/Telegram[0x2baa49b]
/opt/Telegram/Telegram[0x2bfb6d3]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x25c)[0x7fda8fe7c43c]
/usr/lib/libglib-2.0.so.0(+0x9ffa9)[0x7fda8fec9fa9]
/usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x31)[0x7fda8fe7b221]
/opt/Telegram/Telegram[0x2bfb817]
/opt/Telegram/Telegram[0x2ba4e1f]
/opt/Telegram/Telegram[0x2bae616]
/opt/Telegram/Telegram(_ZN4Core7Sandbox5startEv+0x6bc)[0x18f874c]
/opt/Telegram/Telegram(_ZN4Core8Launcher18executeApplicationEv+0xbf)[0x18f93cf]
/opt/Telegram/Telegram(_ZN4Core8Launcher4execEv+0x72)[0x18f94b2]
Google Breakpad caught a crash, minidump written in thread 140576686972288
Minidump: /home/jason/.data/TelegramDesktop/tdata/dumps/d188f986-6d58-4ce2-9d40b2ab-16b8895e.dmp
Backtrace:
/opt/Telegram/Telegram[0xc214bf]
/opt/Telegram/Telegram[0x18fcaf3]
/opt/Telegram/Telegram(_ZN15google_breakpad16ExceptionHandler12GenerateDumpEPNS0_12CrashContextE+0x396)[0x2e77986]
/opt/Telegram/Telegram(_ZN15google_breakpad16ExceptionHandler13SignalHandlerEiP9siginfo_tPv+0xa8)[0x2e77cc8]
/usr/lib/libpthread.so.0(+0x14960)[0x7fda8fe16960]
/opt/Telegram/Telegram(wl_list_remove+0x7)[0x2d0f6b7]
/opt/Telegram/Telegram[0x2d0b7f3]
/opt/Telegram/Telegram(wl_display_dispatch_queue_pending+0x74)[0x2d0cc54]
/usr/lib/libgdk-3.so.0(+0x6701e)[0x7fda5476601e]
/usr/lib/libgdk-3.so.0(gdk_display_manager_open_display+0x116)[0x7fda54794bf6]
/usr/lib/libgtk-3.so.0(gtk_init_check+0x24)[0x7fda782c3aa4]
/opt/Telegram/Telegram[0x13b2082]
/opt/Telegram/Telegram(_ZN8Platform4Libs5startEv+0x67)[0x13b22a7]
/opt/Telegram/Telegram(_ZN10ThirdParty5startEv+0xb)[0x18afc5b]
/opt/Telegram/Telegram(_ZN4Core11Application3runEv+0x1b)[0x1979adb]
/opt/Telegram/Telegram(_ZN4Core7Sandbox6notifyEP7QObjectP6QEvent+0xf5)[0x18b5475]
/opt/Telegram/Telegram[0x2ba5fd9]
/opt/Telegram/Telegram[0x2baa49b]
/opt/Telegram/Telegram[0x2bfb6d3]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x25c)[0x7fda8fe7c43c]
/usr/lib/libglib-2.0.so.0(+0x9ffa9)[0x7fda8fec9fa9]
/usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x31)[0x7fda8fe7b221]
/opt/Telegram/Telegram[0x2bfb817]
/opt/Telegram/Telegram[0x2ba4e1f]
/opt/Telegram/Telegram[0x2bae616]
/opt/Telegram/Telegram(_ZN4Core7Sandbox5startEv+0x6bc)[0x18f874c]
/opt/Telegram/Telegram(_ZN4Core8Launcher18executeApplicationEv+0xbf)[0x18f93cf]
/opt/Telegram/Telegram(_ZN4Core8Launcher4execEv+0x72)[0x18f94b2]
/opt/Telegram/Telegram(main+0x25)[0xbbe385]
/usr/lib/libc.so.6(__libc_start_main+0xf2)[0x7fda8fb03002]
/opt/Telegram/Telegram[0xbc0e8c]
Is this due to the binary having linked something that is incompatible with my current system?
/opt/Telegram/Telegram(wl_list_remove+0x7)[0x2d0f6b7]
Now you're encountered the same issue as in this post https://github.com/telegramdesktop/tdesktop/issues/8005#issuecomment-640186427
Ah, wait @ilya-fedin, I'm confused now, ha.
Yes, it seems to be the same issue, but going by @john-preston's #8005 (comment) I thought it might have been fixed in 2.1.11
, but that's not the case?
but that's not the case?
Unfortunately, no :(
Can the issue be closed?
Most helpful comment
Can the issue be closed?