3 ms·

Having to use magically-blessed (what you call "official") binaries is not a viable strategy either.

cbolton 3y ago
Come on, it's a really good strategy if you care about this (use the official binary, or make the effort of making a static binary yourself). And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system-might-break-by-updating-glibc https://superuser.com/questions/1450027/how-exactly-a-system... I couldn't say the same thing about the LaTeX binaries: $ ldd /usr/bin/pdflatex linux-vdso.so.1 (0x00007ffe347f7000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007e699d5bf000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007e699d5a3000) libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007e699d587000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e699ce00000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007e699d4a0000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e699d47e000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007e699ca00000) /lib64/ld-linux-x86-64.so.2 (0x00007e699d624000) libpng, libz, libkpathsea, libstdc++ are much more likely to break than glibc. $ ldd /usr/bin/lualatex linux-vdso.so.1 (0x00007ffe4f8d6000) libtexlua53.so.5 => /usr/lib/x86_64-linux-gnu/libtexlua53.so.5 (0x00007eccb87c1000) libzzip-0.so.13 => /usr/lib/x86_64-linux-gnu/libzzip-0.so.13 (0x00007eccb9392000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eccb8786000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eccb86b7000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007eccb9376000) libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007eccb8699000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007eccb85b2000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eccb8592000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007eccb8200000) libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eccb8458000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eccb8138000) libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eccb842f000) /lib64/ld-linux-x86-64.so.2 (0x00007eccb93c5000) libpcre.so.3 => /usr/lib/x86_64-linux-gnu/libpcre.so.3 (0x00007eccb80c2000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eccb80b4000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eccb8091000) no comment PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.
mahkoh 3y ago
If you don't know how to build a statically linked rust binary yourself, then why bother posting about the downsides of dynamic linking? And obviously you can also link statically against musl on glibc systems. It's just another library.

Come on, it's a really good strategy if you care about this (use the official binary, or make the effort of making a static binary yourself). And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system-might-break-by-updating-glibc https://superuser.com/questions/1450027/how-exactly-a-system... I couldn't say the same thing about the LaTeX binaries: $ ldd /usr/bin/pdflatex linux-vdso.so.1 (0x00007ffe347f7000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007e699d5bf000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007e699d5a3000) libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007e699d587000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e699ce00000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007e699d4a0000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e699d47e000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007e699ca00000) /lib64/ld-linux-x86-64.so.2 (0x00007e699d624000) libpng, libz, libkpathsea, libstdc++ are much more likely to break than glibc. $ ldd /usr/bin/lualatex linux-vdso.so.1 (0x00007ffe4f8d6000) libtexlua53.so.5 => /usr/lib/x86_64-linux-gnu/libtexlua53.so.5 (0x00007eccb87c1000) libzzip-0.so.13 => /usr/lib/x86_64-linux-gnu/libzzip-0.so.13 (0x00007eccb9392000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eccb8786000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eccb86b7000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007eccb9376000) libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007eccb8699000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007eccb85b2000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eccb8592000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007eccb8200000) libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eccb8458000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eccb8138000) libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eccb842f000) /lib64/ld-linux-x86-64.so.2 (0x00007eccb93c5000) libpcre.so.3 => /usr/lib/x86_64-linux-gnu/libpcre.so.3 (0x00007eccb80c2000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eccb80b4000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eccb8091000) no comment PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.

mahkoh 3y ago

If you don't know how to build a statically linked rust binary yourself, then why bother posting about the downsides of dynamic linking? And obviously you can also link statically against musl on glibc systems. It's just another library.