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

LaTeX (Texlive) on Void musl?


What is my best bet for getting LaTeX (Texlive) setup on musl Void? I saw this: Texlive-bin, auctex, ess on x86_64-musl

(which ends with a rather unencouraging

Best of luck to whoever finds this in Y+3 years!

There is a texlive-bin in the musl repos, but, despite trying a few different approaches, I was unsuccessful in getting anything to run.


The texlive-bin package right now makes use of the official texlive-installer, which provides precompiled binaries. As for nearly every software project offering binaries, that only includes binaries bound to glibc. Therefore you cannot use that one on a musl system (that is not correctly set in the package template, as only_for_archs=...would do)

There have been some attempts to create a xbps-template for manual compilation by xbps-src, none was accepted by now.
github user svenper, chneukirchen and myself have done some work on this. you can try to merge them togther if you like.

Just for completeness: I actually did build the texlive binaries on a x84_64-musl system and compiled some of my latex documents succesfully. So it is possible.
(my template is just not ready for contribution yet).


Thanks, Piraty. Do you think you could point me at where I would find the (not-yet-accepted) templates for building texlive on musl? My (naive) search for this haven’t revealed anything.

Do you think there’s a reasonable way of getting fully working TeXlive working on musl? The other thing I’ve explored is using TeXlive via either Docker or a glibc chroot. The Docker path hasn’t proved very fruitful so far as I still end up with errors when trying to run xelatex. Using a void glibc chroot looks more promising (I’ve got it working - though getting the full scheme of TeXlive on void seems tricky - but figuring out the best way of setting it up to be useable in practice is not trivial).

In other words, whatever solution I choose, some amount of work is required, and so I’m wondering which path (native musl or containerised glibc) would be best.

  1. You can work yourself through the texlive build instruction. the upstream guide is very extensive, but maybe the instructions on linux from scratch can help you.
    You then can use the texlive-install script

  2. Access to TL via glibc chroot/proot (later can be used without root access!) is very well possible.
    I cannot tell about the gui-editor integration to that solution, but i have used the proot variant with success for other tasks that cannot be solved natively on a musl system (java for example).


Thanks, @Piraty. I decided to go for (2) right now, especially given that Texlive 2017 will probably come out within the next month or so, and I don’t feel like trying to rebuild again so soon.

(2) so far has ended up working out pretty well. What I’ve done (in case it’s useful to someone):

  1. bind mount (making sure they have the same path in my chroot as in the ‘host’)
  • my docs directory where my .tex files live
  • my ~/texmf directory
  • my /usr/share/fonts & ~/.fonts directories
  1. make sure in the host that /etc/profile.d/texlive.sh has export PATH=$PATH:/opt/texlive/2016/bin/x86_64-linux (what’s in the chroot /etc/profile.d/ seems to be irrelevant, the chroot seems to inherit the path from the ‘host’)

  2. in /opt/texlive/2016/bin/x86_64-linux (could be anywhere in the PATH, but makes sense to put these here), create +x shell scripts which have the names of the Texlive binaries I want to run (there should be some way of automating this, but for right now I’ve just done tex, pdflatex, latex, xelatex, lualatex, latexmk, biber, bibtex, kpsewhich by hand), which look like this, e.g. for latex:
    #!/bin/sh proot -r /glibchroot latex "$@"

And so far everything seems to work, running my LaTeX editor (Emacs/AUCTeX) in my musl ‘host’.

(A non-musl related tip, to get tlmgr to do a “scheme full” type install, there doesn’t seem to be the expected tlmgr install --all command; the following seems to work though: tlmgr info collections | grep -o 'collection-[A-Za-z]*' | xargs tlmgr install)


Nice work and have fun with you teX-on-musl-setup!
(As always…) when i get to it, i will eventually continue to work on the texlive-bin template :wink: to make it work an every arch, but so far that solution is not bad at all, in fact i may ask you to write up a small article for the wiki that explains the basic steps for setting this up (quick, rough description). Then we can link it to the musl-wiki-page and some other articles where it seems relevant.
After reading your commands more careful i see you make proot-calls for every specific binary. What i referred to in my post was a more radical approach as to proot -S /glibc-chroot into the glibc-environment and run everything in there (for example my java stuff).
But I really see the beauty in your approach, as i didn’t thought of that :wink: rafactoring some of my scripts now, thanks to weekend :wink:

have a look at how the actual template works with it:


Best of luck to whoever finds this in Y+3 years!
– me

Hi again, I’m back! And with a revamped set of templates. I also got biber working.

teckit/template* (libteckit) (libteckit-devel)

biber/template (with 30+ perl module dependencies in parent dir)

There are still some issues like perl-Scalar-List-Utils conflicting by being provided and replaced by the base perl package (and the list of provides/replaces is generated by a perl script I do not understand how to modify, fixed temporarily by deleting a line from the perl template and rebuilding, might be fixed with perl-5.26), and as the new perl dependency modules are not in the official repos yet, xbps-src does not install them automatically when installing biber. I just installed them with xbps as I did with biber and it took a few extra seconds.

Anyway, it’s working. The issues that are left are mostly packaging dependencies correctly and integrating with the texlive-bin package (it also has to be rebuilt with a provides line removed from the template), keeping it from installing binaries for wrong architectures.

*Requires adding the following lines to void-packages/common/shlibs:

libTECkit.so.0 libteckit-2.5.6_1
libTECkit_Compiler.so.0 libteckit-2.5.6_1


I’m about ready to make a pull request for most of the files here (texlive*, *teckit*, lib*, biber, perl-*), but there are some caveats:

  • biber still cannot be packaged without some seemingly major changes to perl I’m not comfortable with, see my previous comment. It fails to run without a newer version of perl-Scalar-List-Utils. Wait for a base perl template upgrade?

  • I try to replicate tlmgr’s package structure, and use new names for the templates to replace. Is my file naming reasonable? The old name for texlive-bin doesn’t make sense for what is now a data files (and scripts) package. And the new binaries package should be named something else to avoid confusion if upgrading.

  • Should there be some kind of integration with tlmgr? Maybe a wrapper script that installs any equivalent xbps binaries? Or post-install scripts for the xbps packages that in turn run tlmgr installing the relevant data files? (is that even possible for subpackages?) Or just a post-install message?

  • I’m unsure how to structure the commits and pull requests. I guess a separate pull request for each template directory (excluding symlinks)? And a single commit in each of those, categorized as “new package” or maybe “revamp”?


Hi! While I am not very experience withe the issues you are presenting I hope this may give you some directions:

About biber: if the issue is only the package upgrade, then wait for it. You may want to open a pull request indicating this problem and the PR should just wait up untill it builds without any mayor problem. Or you could just update the template yourself and push it in the same PR.

I am not well versed with tlmgr… I think Void’s approach to other packages is to use them instead of the main Void repo (so no subpackages). However, this is not true for very wellknown utilities (see perl, python, etc) I believe LaTeX could get a pass with subpackages. But you need to ask the team.

About the PRs. While I haven’t done any, I have seen quite a lot of them. You should call them what they are: a musl fix for (insert package here). Then you can group the changes you have made into PRs, don’t make 10 PRs for different packages when they all belong to the same “group”. Just differenciate PRs when they are either too big or not so related.

Hope it helped you. Thank you for all the work!


Thanks for the input!

That is also how I felt about biber. But at the same time I think that since the developers had no objections to using a very new version of the module, they might do the same thing again in the future, so the same problem could keep happening, stalling our updates for no good reason. The perl template is too complex for me to update, and it also depends on an external cross build system that is currently only builds version 5.24.2. I tried naively updating to 5.26 and disabling the cross build, and it made a package, but when running it complained about missing symbols. There’s quite a bit of patchwork needed I assume.

I’m tempted to make a package like perl-Scalar-List-Utils1.48 that just renames conflicting files with a version suffix (actually only man pages) but that is a bit hacky, though I think less hacky than messing with the core perl package. This seems like a slippery slope, and really only solves my problem of being over-eager… :wink: You are right, the best thing is to wait for updates as it allows simpler maintenance.

(Pavel) #11

Your package collection is a perfect example of why I wish xbps-src wasn’t part of a repository, but a standalone app. It took me way too long to finally get past all the “such and such is not in common/shlibs”.

Huge thanks for making this available for musl! I just started learning TeX and this is -1 to reasons why I still need glibc chroot.


Nice to hear it’s appreciated!

A little progress report:
The perl-Scalar-List-Utils issue was resolved with the 5.26 upgrade. In the meantime I tried to make a script for automatically generating the big texlive template, which was working fine until tlmgr started acting up (still broken), preventing the script from getting the info. I’ll try to work around this some time Soon™ (maybe with inspiration from this that I overlooked), and after that it’s time to get serious about the pull request, I think.


Funny, that we get back to the texlive package at the same time again. :upside_down_face:

Few month back I thought about not packaging all of texlive, but only provide prebuild binaries for each arch by xbps, and still leave the use of tlmgr to install tex packages to the user.
tlmgr has an option to that we can provide binaries (instead of pulling them from official texlive mirrors).
We (or maintainers in the first place) should agree on a modus vivendi in that regard.

Anyway @volleyper, i saw your template-buildup scripts a few weeks back when i brwosed your github, you made some work there indeed!

Drawing inspiration of slackware’s, BLFS’ , arch’s or alpine’s packages could help, but i remember being stuck at some point back then, and alpines was broken (when it still was tl2016).

I propose we combine forces. Please make a centrelized collection of links to your current state f work, so i can give input/PR to that. i’ll cleanup my stuff and provide it too / provide diff to your work.
It’s really time to provide good texlive experience on all archs and glibc!


Packaging this is a long struggle! :face_with_monocle:

That’s what I though as well, and basically what my template is doing. It’s better to let tlmgr do as much of the hard work as possible. Is there a way to make it search for the binaries e.g. on a void server? That way you wouldn’t need to install the entire collection of binaries locally. But it would also maybe be out of scope for xbps. In case that isn’t feasible, I am thinking to make a wrapper for tlmgr that afterwards parses the list of installed packages, compares that to installed xbps packages, and installs/removes the latter as needed. (But this could mess up tlmgr’s post-install scripts if the binaries are missing until afterwards).

My personal opinion:

  • Slackware is good, but they use the texmf data tarball that is only updated once a year
  • BLFS has the same issue but provides good build info and continuous patches
  • Arch is convoluted and but works around the update issue somewhat
  • Alpine is kind of hacky (not that ours wouldn’t be)
  • If we can replicate tlmgr’s structure automatically we don’t need to care about that (and relatively few packages even have binaries)

I will make a void-packages branch. (I did this before but gave up because of shlibs conflicts every time I pulled from upstream, but I’m sure I can find a way to make git make this easier to maintain over time.)


Here is the void-packages branch!
New things are in commits f7837c7 through d80f4d0


When you add your lines not at the end of shlibs but a couple of lines above it, I think you won’t have any conflicts anymore, because the merge needs some context above and below your modification.


sorry i did confuse tlmgr and install-tl, dumb me.
./install-tl -profile void.profile --custom-bin=/opt/texlive2016-installer/custom-bin/ would be the option to provide our binaries. I tested it a few month back, the result seems to be that the upstream binaries are pulled anyway, but the one we point to are used instead.

I see those options:

  1. Void provides full texlive (including tex packages and maybe update it for example every 3 months).
  2. Void provides only texlive’s binaries, so users have to keep up with packages via tlmgr. Binaries would have to be rebuild only when upstream releases updates.

FIrst option is loads of work in maintanance.

Second option is similar to the current state and while wiki.voidlinux.eu already provides a small guide howto use tlmgr, wouldn’t be so hard for unexperienced users afterall. This approach could also let texlive reside in var/texiive just like now.
We could
a. build the binaries in every case – no matter what arch –
b. just build the ones upstream texlive does not support (downside is an uggly template)


Progress update

I made a shell script (when all you have is a hammer…) that generates xbps template functions for subpackages matching the packages, collections and schemes in tlmgr. Note that it only works if texlive thinks it is running a pre-packaged architecture, i.e., if you are running custom-built binaries like these, another ugly hack is required:

Note that I don’t how to reverse these steps; texlive thinks it needs at least one arch if you install that arch after a main installation with -custom-bin.

# tlmgr platform add x86_64-linux
# tlmgr platform set x86_64-linux
# cd /opt/texlive/*/bin/x86_64-musl && cp -a * ../x86_64-linux/

(I would update the post above but think it is locked, probably due to age.)