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=3d00f60242f1726fc6eaa38e09435a969ee7ebe5
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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
