undefined | Better HN

0 pointscrotchfire2y ago0 comments

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.

0 comments

cbolton2y 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/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...

crotchfireOP2y ago

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

mahkoh2y 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.

cbolton2y 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...

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.

j / k navigate · click thread line to collapse

0 pointscrotchfire2y ago0 comments

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 faked your console output.

0 comments

cbolton2y 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/typ...

crotchfireOP2y ago

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

mahkoh2y 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.

cbolton2y 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...

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.

j / k navigate · click thread line to collapse