4 ms·
> does it really need embedding in the executable? Yes, because self-contained executables are massively easier to deploy than ones that have data dependencies
by kentonv 11y ago
> does it really need embedding in the executable?
Yes, because self-contained executables are massively easier to deploy than ones that have data dependencies, because it's just one file that you can put anywhere. Plus you avoid having to write any file I/O code (and deal with potential errors).
Honestly I never understood why this technique is so obscure, rather than being standard practice for C/C++ devs.
> what about the case when you want n blobs of data instead of one?
Each one turns into a .o file, then you link them all together. There's nothing limiting you to just one.
- spoiler 11y agoWell, the only drawback that comes to mind is that you can't mutate the state of that blob (well, you can, but you really really shouldn't). Also if it's obscenely large, it might be better to keep it on disk and load only as much as you need/can.
- icebraining 11y agoAlso if it's obscenely large, it might be better to keep it on disk and load only as much as you need/can. That's what this technique does, since the kernel doesn't fully load the executable file to memory, it'll mmap it but only load data from disk as it's requested.
- spoiler 11y agoI wasn't aware that kernel did that. Now that you said it, it's obvious that they would, but it never actually crossed my mind. Thanks for providing some insight and making me a bit wiser! :-)
- jheriko 11y agothats only true in some cases. in general it is not true.
- kentonv 11y agoWhen is it not true?
- kentonv 11y agoYes, this mostly only makes sense for immutable data.
- jheriko 11y agothats not /need/ its /want/. i'm also not sure i believe you that self contained executables are massively easier to deploy in most cases where the end user is involved. normally they want minimal interaction - if it makes a difference to them how many files it is, then you are doing something even more wrong in how you expect users to deploy - for most users on most platforms it should be an installer or via some app store - possibly both. if you are targeting a very specific type of user then you might well be right, but thats not obvious at all. i asked about the case for n blobs of data because it is unclear where the symbol names come from in your example, and changing them after the fact is not something i would expect people to work out for themselves...
- kentonv 11y agoI primarily had servers in mind. That said, a self-contained executable is super-easy to distribute to a user: They download the executable and then they run it. No need for an installer. When they don't want it anymore they can delete it. That's actually pretty great. That said obviously if you are using some sort of package manager anyway then the benefits are greatly decreased -- effectively, the package becomes the self-contained unit of deployment. The benefit of a self-contained executable is more for cases where bringing in a package manager would create a lot of extra work or if requiring the user to use some particular package manager would be an unacceptable limitation. > it is unclear where the symbol names come from in your example I'm not the author of the article. The symbol name is based on the file name of the input data. This is my least-favorite part of this linker feature -- I have looked for a way to specify a different symbol name but haven't been able to find one. But in any case, yes, different input files will get different symbol names.
- jheriko 11y agoutorrent did this quite well actually... i'm not sure if the installer came to put users at ease, or install malware, but i do miss that quality.