Dear list, I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux. How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure? Cheers, Henri
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure?
Can you please raise that question on the TeX Live mailing list? If TL team is not willing to support it, we can still do it ourselves, but let's first see if there's an "official" way to support it, also with respect to naming. We would need to set up a VM running that version of Linux + some other stuff (at the moment we are experiencing some technical issues with network and the build infrastructure and we need to fix the existing issues first, but then we could look into it). (Would you expect any other use besides you?) Mojca
On 01/20/2018 12:22 AM, Mojca Miklavec wrote:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure?
Can you please raise that question on the TeX Live mailing list?
If TL team is not willing to support it, we can still do it ourselves, but let's first see if there's an "official" way to support it, also with respect to naming. We would need to set up a VM running that version of Linux + some other stuff (at the moment we are experiencing some technical issues with network and the build infrastructure and we need to fix the existing issues first, but then we could look into it).
(Would you expect any other use besides you?)
Definitely the whole community of the Alpine and Void Linux distributions. The Alpine people have a build script in their ports tree, but this does not build LuaJITTeX and---well---you have to build the entire TeXlive yourself which is quite time consuming. https://git.alpinelinux.org/cgit/aports/tree/testing/texlive/APKBUILD https://forum.voidlinux.eu/t/latex-texlive-on-void-musl/2631 Alpine Linux seems to be extremely popular in the container industry, e.g. Docker, and I wanted to base my ConTeXt Docker image on that (but can't at the moment).
Mojca ___________________________________________________________________________________ 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 ___________________________________________________________________________________
On Fri, Jan 19, 2018 at 12:38 PM, Henri Menke
On 01/20/2018 12:22 AM, Mojca Miklavec wrote:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
(Ubuntu 16.04) Following https://www.musl-libc.org/doc/1.0.0/manual.html export PATH=/opt/musl/1.1.18/bin:$PATH export CC='musl-gcc' ./build.sh --parallel --jit 2>&1 | tee out-linux-musl /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2747: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2752: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2760: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `find_symbol': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2789: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `setup_upvals': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3254: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3255: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3257: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3259: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3260: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-call.o): In function `reserve_code': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:175: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:176: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:177: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:178: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:179: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a-call.o):/opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:180: more undefined references to `dlsym' follow /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_sym': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:135: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_load': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:127: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:128: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_unloadlib': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:122: undefined reference to `dlclose' collect2: error: ld returned 1 exit status Makefile:5489: recipe for target 'luatex53' failed make: *** [luatex53] Error 1 strip: 'build/texk/web2c/luajittex': No such file strip: 'build/texk/web2c/luatex53': No such file ls: cannot access 'build/texk/web2c/luajittex': No such file or directory mv: cannot stat 'build/texk/web2c/luatex53': No such file or directory ls: cannot access 'build/texk/web2c/luatex': No such file or directory ..ffi... next thing to fix :-) (btw, the C++ compiler is native g++) -- luigi
Dear Luigi, Thank you very much for taking the time to look into this. I was planning to attempt a native Alpine Linux build next week but the GCC wrapper is a great start. The error message is only a linking error, ffi compiles fine. It seems that luatex is not explicitly linked against libdl.so (which is automatically the case when using glibc aka libc6). In principle this should be easily fixed by adding "-ldl" to the linker flags. Cheers, Henri On 01/20/2018 01:33 AM, luigi scarso wrote:
On Fri, Jan 19, 2018 at 12:38 PM, Henri Menke
wrote: On 01/20/2018 12:22 AM, Mojca Miklavec wrote:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
(Ubuntu 16.04) Following https://www.musl-libc.org/doc/1.0.0/manual.html
export PATH=/opt/musl/1.1.18/bin:$PATH export CC='musl-gcc' ./build.sh --parallel --jit 2>&1 | tee out-linux-musl
/opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2747: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2752: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2760: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `find_symbol': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:2789: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `setup_upvals': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3254: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3255: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3257: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3259: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/ffi.c:3260: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-call.o): In function `reserve_code': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:175: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:176: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:177: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:178: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:179: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a-call.o):/opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/luaffi/call.c:180: more undefined references to `dlsym' follow /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_sym': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:135: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_load': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:127: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:128: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_unloadlib': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53-src/src/loadlib.c:122: undefined reference to `dlclose' collect2: error: ld returned 1 exit status Makefile:5489: recipe for target 'luatex53' failed make: *** [luatex53] Error 1 strip: 'build/texk/web2c/luajittex': No such file strip: 'build/texk/web2c/luatex53': No such file ls: cannot access 'build/texk/web2c/luajittex': No such file or directory mv: cannot stat 'build/texk/web2c/luatex53': No such file or directory ls: cannot access 'build/texk/web2c/luatex': No such file or directory
..ffi... next thing to fix :-)
(btw, the C++ compiler is native g++)
I successfully compiled LuaTeX trunk in the Alpine Docker container. Steps to reproduce: Start the Docker container using `sudo docker run -it alpine:edge` Inside the container: apk update apk add subversion bash gcc g++ make texinfo svn co --username anonsvn --password anonsvn https://serveur-svn.lri.fr/svn/modhel/luatex/trunk cd trunk ./build.sh --parallel --jit 2>&1 | tee out-linux-musl After that I have: /trunk # ldd build/texk/web2c/luatex /lib/ld-musl-x86_64.so.1 (0x7f60dedc9000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f60dedc9000) /trunk # ldd build/texk/web2c/luajittex /lib/ld-musl-x86_64.so.1 (0x7f9814229000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f9814229000) I could not yet test it because I'd have to create texmf.cnf and formats. On Sat, 2018-01-20 at 16:13 +1300, Henri Menke wrote:
Dear Luigi,
Thank you very much for taking the time to look into this. I was planning to attempt a native Alpine Linux build next week but the GCC wrapper is a great start. The error message is only a linking error, ffi compiles fine. It seems that luatex is not explicitly linked against libdl.so (which is automatically the case when using glibc aka libc6). In principle this should be easily fixed by adding "-ldl" to the linker flags.
Cheers, Henri
On 01/20/2018 01:33 AM, luigi scarso wrote:
On Fri, Jan 19, 2018 at 12:38 PM, Henri Menke
wrote: On 01/20/2018 12:22 AM, Mojca Miklavec wrote:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
(Ubuntu 16.04) Following https://www.musl-libc.org/doc/1.0.0/manual.html
export PATH=/opt/musl/1.1.18/bin:$PATH export CC='musl-gcc' ./build.sh --parallel --jit 2>&1 | tee out-linux-musl
/opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:2747: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:2752: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:2760: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `find_symbol': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:2789: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a-ffi.o): In function `setup_upvals': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:3254: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:3255: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:3257: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:3259: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/ffi.c:3260: undefined reference to `dlopen' liblua53ffi.a(liblua53ffi_a-call.o): In function `reserve_code': /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/call.c:175: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/call.c:176: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/call.c:177: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/call.c:178: undefined reference to `dlsym' /opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luatexdir/lu affi/call.c:179: undefined reference to `dlsym' liblua53ffi.a(liblua53ffi_a- call.o):/opt/svn/temp/experimental/experimental/build/texk/web2c/../../../source/texk/web2c/luat exdir/luaffi/call.c:180: more undefined references to `dlsym' follow /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_sym': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53- src/src/loadlib.c:135: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_load': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53- src/src/loadlib.c:127: undefined reference to `dlopen' /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53- src/src/loadlib.c:128: undefined reference to `dlerror' /opt/svn/temp/experimental/experimental/build/libs/lua53/.libs/libtexlua53.a(loadlib.o): In function `lsys_unloadlib': /opt/svn/temp/experimental/experimental/build/libs/lua53/../../../source/libs/lua53/lua53- src/src/loadlib.c:122: undefined reference to `dlclose' collect2: error: ld returned 1 exit status Makefile:5489: recipe for target 'luatex53' failed make: *** [luatex53] Error 1 strip: 'build/texk/web2c/luajittex': No such file strip: 'build/texk/web2c/luatex53': No such file ls: cannot access 'build/texk/web2c/luajittex': No such file or directory mv: cannot stat 'build/texk/web2c/luatex53': No such file or directory ls: cannot access 'build/texk/web2c/luatex': No such file or directory
..ffi... next thing to fix :-)
(btw, the C++ compiler is native g++)
On 1/21/2018 2:04 AM, Henri wrote:
I could not yet test it because I'd have to create texmf.cnf and formats. can't you just take the standalone and replace binaries?
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Sun, 2018-01-21 at 11:53 +0100, Hans Hagen wrote:
On 1/21/2018 2:04 AM, Henri wrote:
I could not yet test it because I'd have to create texmf.cnf and formats.
can't you just take the standalone and replace binaries?
Good idea! I did that and it works. In that process I noticed that the setuptex script doesn't have a shebang but requires bash compatibility. Could you please add #!/bin/bash to the script as the very first line? Also, I only replaced the following binaries: kpseaccess kpsestat kpsewhich luajittex luatex Thus the following binaries remain untested by me: afm2pl afm2tfm bibtex dvipos dvips mpost pdfclose pdfopen pltotf tftopl vftovp vptovf
----------------------------------------------------------------- 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 ___________________________________________________________________________________
On Mon, 22 Jan 2018 09:49:49 +1300
Henri
In that process I noticed that the setuptex script doesn't have a shebang but requires bash compatibility. Could you please add
#!/bin/bash
to the script as the very first line?
NO!!!! Nothing in it should be BAsh requiring, so this script works (or should work) with sh, zsh, bash, ... (which is why there is a separate setuptex.csh). Alan
On 1/21/2018 9:49 PM, Henri wrote:
On Sun, 2018-01-21 at 11:53 +0100, Hans Hagen wrote:
On 1/21/2018 2:04 AM, Henri wrote:
I could not yet test it because I'd have to create texmf.cnf and formats.
can't you just take the standalone and replace binaries?
Good idea! I did that and it works. In that process I noticed that the setuptex script doesn't have a shebang but requires bash compatibility. Could you please add
#!/bin/bash
to the script as the very first line?
Also, I only replaced the following binaries:
kpseaccess kpsestat kpsewhich luajittex luatex
if you use only luatex, you need luatex and optionally luajittex, nothing more
Thus the following binaries remain untested by me:
afm2pl afm2tfm bibtex dvipos dvips mpost pdfclose pdfopen pltotf tftopl vftovp vptovf Te font ones are only needed when you doi special things with fonts and use mkii; mpost is not needed ad luatex can drop in; dvi* is only needed for some special cases in mkii and th epdf* ones are somewhat special
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 -----------------------------------------------------------------
On Sun, Jan 21, 2018 at 9:49 PM, Henri
Thus the following binaries remain untested by me: : mpost mpost can be done in the same manner as luatex, the repository is the same https://serveur-svn.lri.fr/svn/modhel/metapost
-- luigi
Am Freitag, den 19.01.2018, 12:22 +0100 schrieb Mojca Miklavec:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.mus l-libc.org/) instead of glibc, like for instance Alpine Linux.
How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure?
Can you please raise that question on the TeX Live mailing list?
If TL team is not willing to support it, we can still do it ourselves, but let's first see if there's an "official" way to support it, also with respect to naming.
You can link musl statically which makes these binaries run basically everywhere, so it's actually a win for everybody. The only downsides of musl against libc that I am aware of are some restrictions in DNS lookups (it doesn't use NSS) and that it may not link easily against C++ ... but that should be a one-time-fix at source code level and full fledged DNS support shouldn't matter for TeX anyway. Anyway: IMHO it's worth it and I'm also all for it since I prefer Alpine as well :D (I compile my projects using Alpine as well and statically link it against musl to have binaries that run on all possible linux distributions independant of their underlying libc.) Best regards Andreas
On Mon, 2018-01-22 at 20:09 +0100, Andreas Schneider wrote:
Am Freitag, den 19.01.2018, 12:22 +0100 schrieb Mojca Miklavec:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.mus l-libc.org/) instead of glibc, like for instance Alpine Linux.
How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure?
Can you please raise that question on the TeX Live mailing list?
If TL team is not willing to support it, we can still do it ourselves, but let's first see if there's an "official" way to support it, also with respect to naming.
You can link musl statically which makes these binaries run basically everywhere, so it's actually a win for everybody.
You cannot link musl statically if you use the dynamic linker (dlopen) which is needed for the FFI in LuaTeX and LuaJITTeX. Just search online for "musl dlopen", e.g. with Google https://google.com/search?q=musl%20dlopen
The only downsides of musl against libc that I am aware of are some restrictions in DNS lookups (it doesn't use NSS) and that it may not link easily against C++ ... but that should be a one-time-fix at source code level and full fledged DNS support shouldn't matter for TeX anyway.
Anyway: IMHO it's worth it and I'm also all for it since I prefer Alpine as well :D (I compile my projects using Alpine as well and statically link it against musl to have binaries that run on all possible linux distributions independant of their underlying libc.)
Best regards Andreas ___________________________________________________________________________________ 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 ___________________________________________________________________________________
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 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? 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 On Fri, 2018-01-19 at 12:22 +0100, Mojca Miklavec wrote:
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.or g/) instead of glibc, like for instance Alpine Linux.
How would I go about this? Can you share existing build scripts for, e.g. Linux-64? Do I have to provide build infrastructure?
Can you please raise that question on the TeX Live mailing list?
If TL team is not willing to support it, we can still do it ourselves, but let's first see if there's an "official" way to support it, also with respect to naming. We would need to set up a VM running that version of Linux + some other stuff (at the moment we are experiencing some technical issues with network and the build infrastructure and we need to fix the existing issues first, but then we could look into it).
(Would you expect any other use besides you?)
Mojca ______________________________________________________________________________ _____ 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 ______________________________________________________________________________ _____
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.) - It would help to have a simple patch for http://distribution.contextgarden.net/setup/first-setup.sh to correctly detect the platform - 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
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. Mojca
On Wed, Jan 31, 2018 at 10:26 AM, Mojca Miklavec
- 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.) I wonder, the things are the same from at least one year (perhaps two): texlive <-> tags garden <-> trunk only hans. <-> experimental
-- luigi
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 -----------------------------------------------------------------
On 19 January 2018 at 11:40, Henri Menke wrote:
Dear list,
I'd like to support Linux platforms which use musl (https://www.musl-libc.org/) instead of glibc, like for instance Alpine Linux.
I have added the TeX Live binaries. So in principle this could work now: rsync -ptv rsync://contextgarden.net/standalone/setup/first-setup.sh . ./first-setup.sh but I suspect that some changes in mtxrun might be needed for this to work properly. Mojca
participants (7)
-
Alan Braslau
-
Andreas Schneider
-
Hans Hagen
-
Henri
-
Henri Menke
-
luigi scarso
-
Mojca Miklavec