Home | News | Download | Packages | Forum | Wiki | Github

Telegram on musl

(Piotr) #1

I am using musl version of void and would like to be able to run Telegram. I used to use a binary from the telegram’s page, which while a questionable seciurity, provided a single file executable with no dependencies. The problem is that it is linked with glibc.

Did anyone managed to statically compile telegram client for musl?

If the package template for staticly linked build would be accepted to the void-packages repository, such package would appear for both glibc and musl repositories. Is that right?


I personally just use pidgin with the Telegram plugin. You can also try to use Cutegram as another alternative (which is AFAIK on the musl repo)

Edit: fixed missing space

(Adomas Jackevičius) #5

I tried using Cutegram, but for me it seg faults almost on every action in app… Void Linux x86_64-musl

Anyway Telegram is open source, no? Maybe in future we can expect Telegram musl package?

(rain1) #6

I would recommend against using telegram if at all possible.


Telegram is open source but it needs a lot of patches for musl

(4130) #8

You could always set up a chroot that uses glibc and write a script to chroot in and execute your telegram binary. I’m thinking most people in your position that need to run glibc binaries on musl systems do this, I have never done so but it should work.

The wiki has some info on this:

Alpine also covers this topic:


The last time I looked at the telegram desktop client it required a patched version of QT, which makes building and patching it really complicated.
QT is very large and building it takes ages and you still have to patch and maintain musl patches for it too.


Arch Linux is shipping Telegram without patched qt5 (qt 5.10.x), but idk which qt5 version is the minimum, but 5.8.0 is probably too old. But Telegram itself will probably still need a lot of musl patches ( e.g. google breakpad)


You can use the flatpak version of Telegram until it is in the repo. I just rechecked Cutegram and it seems that the development has stopped


Flatpak?! Personally, I would try to use containers instead.


Flatpak is imo the easier solution, but w/e everyone has his/her personal preferences.

edit: typo as always


Respect! Flatpak may be the easiest solution…
I just don’t really like Flatpak, at the end of the day, it comes from Red Hat…, well, kind of

(Piotr) #15

Thanks. I think for now I will continue using web interface.

Chroot looks to me like the best of options, but using it seems to defeat the purpose of using musl.


containers is slightly more secure than chroot and works, IMHO in a similar way. Check the links bellow and decide for yourself. Hope you will enjoy Void musl as much as I do :rofl:


I finally got Telegram working on musl.


@rain1 , @JohnZ Personnally I don’t trust Telegram. “Secret Chat” ? No it’s not.

(Leszek Cimała) #19

While I agree, that paranoia is good when using technology, flatpak is quite nice thing in my opinion. Yes it is technically Red Hat thingy, but not only and many things we use are from Red Hat (or they people are involved in upstream), but I personally think it is good. Many projects would be not as advanced, nor stable without them.
Of course, usually their primary goals are to fulfill needs of their distros or customers, but still, they are writing open source code, which we can read, analyze and use. It is not evil company in my opinion, I think quite opposite. They are giving back to communities much more, then other companies. I says that despite that I personally was never big fan of they distros.

Flatpak is just kind of desktop oriented containers, but I personally think, it adds a lot of value, allows nice integration (exported mime, icons, granular rights control …).
And I think, that it is great solution for muslc distros. It allows us easily use proprietary stuff, or app, which are complicated to compile with muslc.

Another great thing is, that usually upstream is managing their apps in flatpak, so they are actual and usually well behaving.

And yes, there are alternatives, but nothing is so easy for end users as flatpak.

Just my 2 cents. :wink:


Yeap! What about the multiple libraries on your system taking more and more disk space? What about the future freedom of choice, if devs decide to only supply stuff through flatpak/snaps/appimage? Personally, I really dislike it but, that’s just me. The future will tell!?!

(Leszek Cimała) #21

Well, I see your points, and agree that devs supplying only selected images is dangerous … but it is like that already! How many bigger projects supply Void Linux, Alpine Linux (even Arch Linux) packages? Not many if any. Our great maintainers have to do heavy lifting and container technology will not make it harder for them.

The same risk is with docker, and I saw that already, instead of providing good docs - well here you have docker image … not cool, but we always can look into templates. And if dev is lazy, nothing will help. :wink:

There is ostree under the hood of flatpak, deduplication is very strong, thats first, second, what is few MiBs nowadays … with such minimalists distros like Void, we all have plenty of space :smiley:.