5 ms·

That old binary won't link with the shared libraries on your machine 10 years from now. Depends on 280 other crates. Ye gads. "Yeah just use ancient binaries

That old binary won't link with the shared libraries on your machine 10 years from now. Depends on 280 other crates. Ye gads. "Yeah just use ancient binaries" is not a viable strategy for future-proofing. It's a lot easier to move fast and break things when you don't care about stability.

cbolton 3y ago
$ ldd bin/typst statically linked
- crotchfire 3y ago
  You faked this. `ldd` never prints just the text `statically linked` for a statically-linked binary. Here's the real output. $ ldd result/bin/typst linux-vdso.so.1 (0x00007ffd2c4e5000) libgcc_s.so.1 => /nix/store/28d6zz06v3mpwdbi72fdw64qmmq8rhfm-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007f4fe68b9000) libm.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libm.so.6 (0x00007f4fe67d9000) libc.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libc.so.6 (0x00007f4fe4619000) /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/ld-linux-x86-64.so.2 => /nix/store/7v29y7b3b38x2hpgld698fw6k5mffam8-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f4fe68e1000) You can't have truly statically linked binaries on glibc systems; they ditched support for that over a decade ago. On the 1% of Linux systems using Musl you can produce statically-linked binaries, but `ldd` will report `not a dynamic executable`. You faked your console output.
  - cbolton 3y ago
    It's not faked. I guess the nix recipe does things differently from the official binary. Try yourself: https://github.com/typst/typst/releases/download/v0.11.0/typst-x86_64-unknown-linux-musl.tar.xz https://github.com/typst/typst/releases/download/v0.11.0/typ... But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...
    - deleted 3y ago
      [deleted]
    - crotchfire 3y ago
      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.

cbolton 3y ago

$ ldd bin/typst statically linked

crotchfire 3y ago
You faked this. `ldd` never prints just the text `statically linked` for a statically-linked binary. Here's the real output. $ ldd result/bin/typst linux-vdso.so.1 (0x00007ffd2c4e5000) libgcc_s.so.1 => /nix/store/28d6zz06v3mpwdbi72fdw64qmmq8rhfm-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007f4fe68b9000) libm.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libm.so.6 (0x00007f4fe67d9000) libc.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libc.so.6 (0x00007f4fe4619000) /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/ld-linux-x86-64.so.2 => /nix/store/7v29y7b3b38x2hpgld698fw6k5mffam8-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f4fe68e1000) You can't have truly statically linked binaries on glibc systems; they ditched support for that over a decade ago. On the 1% of Linux systems using Musl you can produce statically-linked binaries, but `ldd` will report `not a dynamic executable`. You faked your console output.
- cbolton 3y ago
  It's not faked. I guess the nix recipe does things differently from the official binary. Try yourself: https://github.com/typst/typst/releases/download/v0.11.0/typst-x86_64-unknown-linux-musl.tar.xz https://github.com/typst/typst/releases/download/v0.11.0/typ... But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...
  - deleted 3y ago
    [deleted]
  - crotchfire 3y ago
    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.