[HN Gopher] Clodl: Turn dynamically linked ELF binaries into sel...
___________________________________________________________________
Clodl: Turn dynamically linked ELF binaries into self-contained
closures
Author : vsurabhi
Score : 41 points
Date : 2021-05-03 10:11 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| q3k wrote:
| Great! I was considering writing some Bazel rules for _exactly_
| this yesterday.
| jart wrote:
| Author should consider using Actually Portable Executable for the
| bootstrapper.
| CalChris wrote:
| How is this different from prelink?
|
| https://linux.die.net/man/8/prelink
| saagarjha wrote:
| Prelinking just attempts to fix up load addresses so there are
| no conflicts at runtime that require relocations; it doesn't
| bundle the libraries and as such solves a fundamentally
| different problem.
| ris wrote:
| Nix can do this for basically anything - even python scripts with
| all their dependency modules, binary extensions and all dynamic
| lib dependencies, packed up into a single .nar file.
|
| nix-shell can even be used as a shebang-line for scripts:
| https://nixos.org/manual/nix/stable/#use-as-a-interpreter
| fao_ wrote:
| That is, given a shared library or a position independent
| executable (PIE), it returns a single, self-contained file
| packing all dependencies. [...] but closures do
| allow for deploying to other machines without concerns
| about missing dependencies.
|
| So. It's a statically linked binary, but worse? Or like a PAR
| file, but for C? I'm really not sure what the benefits are here
| over statically linked binaries.
|
| In fact, since it extracts to a directory in /tmp, it seems to be
| worse in comparison -- since you have to take the increase in
| size into account.
|
| I really do not see what the point of this is, or what niche it's
| supposed to fill over flatpaks or appimages (which both have
| sandboxing), or why you would pick this over static libraries --
| can someone explain this?
| Wowfunhappy wrote:
| Pretty please, tell me how to compile static binaries and I'll
| do that forever. I always end up with certain external
| libraries still being required.
| jart wrote:
| Use Cosmopolitan Libc. Everything is statically linked. See
| for example https://justine.lol/redbean/index.html don't you
| want binaries like that?
| hctaw wrote:
| You need to compile a static executable (not with static
| libraries, there's a subtle difference). The flags depend on
| your compiler.
|
| If you're on Linux, musl libc and musl-tools are useful for
| dealing with this reliably.
| a1369209993 wrote:
| > You need to compile a static executable
|
| This is functionally impossible on $ISA-linux-gnu, because
| the glibc developers refuse to provide a working C standard
| library (libc.a).
|
| > musl libc and musl-tools are useful
|
| Sure, but if the software worked (/reliably) with musl,
| we'd be using that already.
| gravypod wrote:
| My guess is that the benefit is they can write their
| applications in Haskell, package up the binary into a JVM
| application/shim (which can be templated in a bazel macro) and
| deploy a service into something like AWS Lambda or existing
| infrastructure for their clients. They're a consultancy that
| favors Haskell https://www.tweag.io/services
| cmm wrote:
| when have you last tried to create a statically-linked binary
| that used glibc, and how did that go for you? or how about
| statically relinking a dynamically-linked binary you don't have
| sources for?
|
| (but hey, I also felt cheated when I read how clodl works. the
| hope for magic is always there, isn't it)
| fao_ wrote:
| > when have you last tried to create a statically-linked
| binary that used glibc, and how did that go for you?
|
| I don't write code that requires Glib, but last I remember,
| there are explicit (lesser-known) flags that give complete
| static independence :P
|
| My implicit point is that essentially, there is a slew of
| approaches that seem to be reinventing the wheel to solve the
| obvious problems in dynamic linking, but they seem to combine
| the problems of static linking with the problems of dynamic
| linking. Because people have the memoized knowledge that
| "static linking old and bad", they twist software into worse
| solutions because what they _want_ are static libraries and
| binaries, but for whatever reason they don 't feel they can
| use them.
|
| > or how about statically relinking a dynamically-linked
| binary you don't have sources for?
|
| Most open source developers don't tend to stray _that_ far
| off the beaten path, at least in the communities where snap
| /flatpak/appimage are commonly used.
| geggam wrote:
| >Because people have the memoized knowledge that "static
| linking old and bad",
|
| It feels to me that the container mentality wants to
| abstract the complexity of the computing to the point they
| are creating issues that were solved before then layering
| that on a complex OS and pretending the OS isnt required |
|
| At some point software has to sit on hardware...
| mhitza wrote:
| > I don't write code that requires Glib, but last I
| remember, there are explicit (lesser-known) flags that give
| complete static independence :P
|
| I wouldn't mind if there was some quick way of doing this.
| I would like to statically link a bunch of commandline
| utilies that I'd like to just copy in my home folder on
| various servers without installing them globally.
|
| Granted, I'm not a C developer so I just searched for
| answers on statically linking, but I never was able to
| easily create these binaries (with a few exceptions). If I
| recall correctly I had to individually compile dependencies
| to be able to statically link to those as well (and a bunch
| of C_FLAGS/LD_LIBRARY_PATH/INCLUDE_PATH env vars sprinkled
| everywhere to wire all those up).
|
| If someone has a bash script gcc-static-link that I can use
| as a wrapper around gcc I'd be more than happy to hear
| about it :)
| pengaru wrote:
| > I don't write code that requires Glib, but last I
| remember, there are explicit (lesser-known) flags that give
| complete static independence :P
|
| Glib != glibc
| choeger wrote:
| > or how about statically relinking a dynamically-linked
| binary you don't have sources for?
|
| Even though I don't know why you would do that, I think you
| _could_ do it by running a modified version of the dynamic
| linker. That thing basically runs like an interpreter for
| your binary. It links the code and then executes it. It
| should not be impossible to modify it to instead dump your
| ELF again, no?
___________________________________________________________________
(page generated 2021-05-03 23:01 UTC)