On 1/31/2018 10:26 AM, Mojca Miklavec wrote:
On 30 January 2018 at 00:23, Henri wrote:
It looks like we are going to get upstream support for musl from TeX live.
There is this extremely long thread on the tlbuild mailing list. https://tug.org/pipermail/tlbuild/2018q1/003972.html
Thanks a lot. This *enormously* simplifies things. (After your initial reply to the tlbuild I nearly lost hope, please don't repeat such attempts ... :)
An automated build on Alpine Linux has been included in the TeX live continuous integration on GitHub. https://github.com/TeX-Live/texlive-source/blob/master/.travis.yml
What would I have to do in order to get an automated build for ConTeXt standalone for musl?
- We need "the latest" luatex. (It's not yet clear to me what "the latest" means at this moment as it's still totally confusing to me and we didn't configure the other builders yet either. Luigi sent me a relatively confusing message about which branch should be used.)
We have release (1.07), trunk (also 1.07 but more modern and hipper as it does lua 53) and experimental (our playground). The garden can use trunk while texlive uses release.
- It would help to have a simple patch for http://distribution.contextgarden.net/setup/first-setup.sh to correctly detect the platform
someone has to provide that then as i have no clue (i use opensuse on servers which works out of the box and linux subsystem on windows which also works ok)
- I would copy the TL binaries from you for now and later take them from the subversion repository (I assume that would happen once the updates are frozen).
Hans might be interested in detecting musl libc automatically, which I have recently merged into GNU autotools: https://git.savannah.gnu.org/cgit/config.git/commit/?id=3d00f60242f1726fc6ea... It uses ldd to detect whether musl is used because ldd prints "musl libc" to stderr. https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1538
Does that really matter then? Aren't those system libs loaded by luatex itself?
That's something which I still believe should be somehow "hardcoded" into LuaTeX itself, so that LuaTeX itself would be aware of which platform it was compiled for. At the moment part of detection happens in mtxrun, but that's somewhat strange.
There is some code in luatex but the more one hard-codes the worse it gets when it's wrong. Only the shell knows ... (we had these many many hardcodes paths in some texmf vars long ago ... failures). In the end, all that is needed to know the binary path. In fact, if texlive wasn't multi-platform-at-the-same-time we could let all binaries fly to tex/texmf-binaries Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------