Clodl: Turn dynamically linked ELF binaries into self-contained closures
1–10 of 29 posts
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#2 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.
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?
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#3That 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, sinc…
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)
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#4That 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, sinc…
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
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#5Great! I was considering writing some Bazel rules for _exactly_ this yesterday.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#6That 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, sinc…
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)
> 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.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#7That 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, sinc…
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)
> 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?
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#8That 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, sinc…
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.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#9Earlier quoted context omitted.
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)
> 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 se…
> 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 :)
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#10Earlier quoted context omitted.
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)
> 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 se…
> 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