4 ms·

> every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Back in the dark ages,

by retrac 6y ago

> every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Back in the dark ages, some mainframe operating systems like MVS normally stored executables as object files, and would link the program every time you executed it. Has the on-disk space savings and updateable libraries of dynamic linking, without most of the complexity. I believe the original motivation was to allow an executable to run at an arbitrary address on systems without virtual memory though.

1996 6y ago
I would be surprised if there was not a way to take a dynamic executable, "add in" all the required libraries, and return a fat static executable
- AnIdiotOnTheNet 6y ago
  If you know of such a utility I'd like to see it, because I've looked and never found it. The closest I've seen are things like AppImage.
  - 1996 6y ago
    Shell scripting and ld tools should allow you to make that yourself. EDIT: people are apparently entitled to solutions for their problems... > Care to elaborate? > Show us a script then! Your internet fame awaits. I'm not interested in fame, or in reinventing the wheel. Apparently, you are unfamiliar with this process, so TLDR: there are basically 2 approaches, in order of complexity: 1. working with ldtools or 2. running the executable to find the various parts then dumping a binary, (3 if you consider putting the libraries in a directory then run with LD_LIBRARY_PATH=/thisdir myexecutable) Let me google some existing tools for you: https://github.com/systems-nuts/dynamic_to_static https://github.com/systems-nuts/dynamic_to_static http://bitwagon.com/jumpstart/jumpstart.html http://bitwagon.com/jumpstart/jumpstart.html http://statifier.sourceforge.net/ http://statifier.sourceforge.net/ https://www.ucc.asn.au/~dagobah/things/make-static.html https://www.ucc.asn.au/~dagobah/things/make-static.html https://web.archive.org/web/20130114222319if_/http://dagobah.ucc.asn.au/wacky/cryopid-0.5.9.1-x86_64.tar.gz https://web.archive.org/web/20130114222319if_/http://dagobah... with patch and explanation on https://stackoverflow.com/questions/17390722/how-can-i-convert-dynamically-linked-application-to-statically-one https://stackoverflow.com/questions/17390722/how-can-i-conve... A better approach from 15 years ago is slinky, so that you can "update" the libraries if needed: https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html https://www.usenix.org/legacy/publications/library/proceedin... There's nothing fancy in there. It just requires some effort.
    - AnIdiotOnTheNet 6y ago
      Care to elaborate? Because I'm not aware of any tool that could be used to combine a binary and all its .so dependencies (and all of theirs recursively) into a single statically-linked binary.
    - dTal 6y ago
      Show us a script then! Your internet fame awaits.
  - throwaway894345 6y ago
    It exists. I came across at least one such project last year, but I don't recall the name. :(
  - efrecon 6y ago
    I have used exodus to do this in the past. https://github.com/intoli/exodus https://github.com/intoli/exodus
    - AnIdiotOnTheNet 6y ago
      > Exodus handles bundling all of the binary's dependencies, compiling a statically linked wrapper for the executable that invokes the relocated linker directly, and installing the bundle in ~/.exodus/ on the remote machine. You can see it in action here. That isn't really what is being described, or at least not what I'm referring to. It's more like a self-extractor.
      - efrecon 6y ago
        You are right. My mistake. I remembered it wrong.
- girvo 6y ago
  My admittedly poor understand of macOS application bundles, is that is basically how they work (modulo certain Frameworks in Library folders)
robocat 6y ago
It was for personal operating systems (and ancient mainframes) that had a multitasking OS but without any MMU support in the hardware. Relocatable executables were required so that you could load multiple executables at different addresses within the single address space of the memory. This is now called Position Independent Code[1]. Modern MMUs meant that the OS would define specific addresses for use by a program, so for example all ELF programs in a distribution would have the same starting address in memory hard coded into the executable (one virtual address within a process is mapped to a different physical memory address for each process by the MMU). [1] https://en.wikipedia.org/wiki/Position-independent_code https://en.wikipedia.org/wiki/Position-independent_code
- Someone 6y ago
  There’s a difference. Position independent means you can move the executable anywhere and run it. Relocatable means the binary has enough information to fix any absolute addresses in the code after that move. That’s extra work, and means you cannot have the same physical memory mapped to different virtual addresses in different processes, and that you have to either swap out the relocated memory, or repeat the relocation when you swap in the code again (I’m not aware of any OS doing the latter, and don’t see a nice way to do it, but it is a possibility). https://en.wikipedia.org/wiki/Position-independent_code https://en.wikipedia.org/wiki/Position-independent_code: “In computing, position-independent code[1] (PIC[1]) or position-independent executable (PIE)[2] is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address.” https://en.wikipedia.org/wiki/Relocation_(computing) https://en.wikipedia.org/wiki/Relocation_(computing): “Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses.”

by retrac 6y ago

1996 6y ago

I would be surprised if there was not a way to take a dynamic executable, "add in" all the required libraries, and return a fat static executable

AnIdiotOnTheNet 6y ago
If you know of such a utility I'd like to see it, because I've looked and never found it. The closest I've seen are things like AppImage.
- 1996 6y ago
  Shell scripting and ld tools should allow you to make that yourself. EDIT: people are apparently entitled to solutions for their problems... > Care to elaborate? > Show us a script then! Your internet fame awaits. I'm not interested in fame, or in reinventing the wheel. Apparently, you are unfamiliar with this process, so TLDR: there are basically 2 approaches, in order of complexity: 1. working with ldtools or 2. running the executable to find the various parts then dumping a binary, (3 if you consider putting the libraries in a directory then run with LD_LIBRARY_PATH=/thisdir myexecutable) Let me google some existing tools for you: https://github.com/systems-nuts/dynamic_to_static https://github.com/systems-nuts/dynamic_to_static http://bitwagon.com/jumpstart/jumpstart.html http://bitwagon.com/jumpstart/jumpstart.html http://statifier.sourceforge.net/ http://statifier.sourceforge.net/ https://www.ucc.asn.au/~dagobah/things/make-static.html https://www.ucc.asn.au/~dagobah/things/make-static.html https://web.archive.org/web/20130114222319if_/http://dagobah.ucc.asn.au/wacky/cryopid-0.5.9.1-x86_64.tar.gz https://web.archive.org/web/20130114222319if_/http://dagobah... with patch and explanation on https://stackoverflow.com/questions/17390722/how-can-i-convert-dynamically-linked-application-to-statically-one https://stackoverflow.com/questions/17390722/how-can-i-conve... A better approach from 15 years ago is slinky, so that you can "update" the libraries if needed: https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html https://www.usenix.org/legacy/publications/library/proceedin... There's nothing fancy in there. It just requires some effort.
  - AnIdiotOnTheNet 6y ago
    Care to elaborate? Because I'm not aware of any tool that could be used to combine a binary and all its .so dependencies (and all of theirs recursively) into a single statically-linked binary.
  - dTal 6y ago
    Show us a script then! Your internet fame awaits.
- throwaway894345 6y ago
  It exists. I came across at least one such project last year, but I don't recall the name. :(
- efrecon 6y ago
  I have used exodus to do this in the past. https://github.com/intoli/exodus https://github.com/intoli/exodus
  - AnIdiotOnTheNet 6y ago
    > Exodus handles bundling all of the binary's dependencies, compiling a statically linked wrapper for the executable that invokes the relocated linker directly, and installing the bundle in ~/.exodus/ on the remote machine. You can see it in action here. That isn't really what is being described, or at least not what I'm referring to. It's more like a self-extractor.
    - efrecon 6y ago
      You are right. My mistake. I remembered it wrong.
girvo 6y ago
My admittedly poor understand of macOS application bundles, is that is basically how they work (modulo certain Frameworks in Library folders)

robocat 6y ago

It was for personal operating systems (and ancient mainframes) that had a multitasking OS but without any MMU support in the hardware. Relocatable executables were required so that you could load multiple executables at different addresses within the single address space of the memory. This is now called Position Independent Code[1]. Modern MMUs meant that the OS would define specific addresses for use by a program, so for example all ELF programs in a distribution would have the same starting address in memory hard coded into the executable (one virtual address within a process is mapped to a different physical memory address for each process by the MMU). [1] https://en.wikipedia.org/wiki/Position-independent_code https://en.wikipedia.org/wiki/Position-independent_code

Someone 6y ago
There’s a difference. Position independent means you can move the executable anywhere and run it. Relocatable means the binary has enough information to fix any absolute addresses in the code after that move. That’s extra work, and means you cannot have the same physical memory mapped to different virtual addresses in different processes, and that you have to either swap out the relocated memory, or repeat the relocation when you swap in the code again (I’m not aware of any OS doing the latter, and don’t see a nice way to do it, but it is a possibility). https://en.wikipedia.org/wiki/Position-independent_code https://en.wikipedia.org/wiki/Position-independent_code: “In computing, position-independent code[1] (PIC[1]) or position-independent executable (PIE)[2] is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address.” https://en.wikipedia.org/wiki/Relocation_(computing) https://en.wikipedia.org/wiki/Relocation_(computing): “Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses.”