[…] or maybe you try “-static-libstdc++” to drop the dependency entirely (and grow the binary accordingly).
I work in the embedded sphere where everything is statically linked. And damn, things are a lot easier. I’m really liking the idea that if the binary size isn’t insane, deploy a static binary where possible. If you can, build libraries with -ffunction-sections and the linker can remove sections that aren’t referenced.
Added bonus: you may not have to build the code on the target system.
Now you get to play the “oh, I want you to use the new libstdc++ over in some weird separate path” game. This is when you start playing with “-rpath” (which itself starts getting mighty spooky when you start playing with $ORIGIN) or maybe you try “-static-libstdc++” to drop the dependency entirely (and grow the binary accordingly).
Excuse me, do you have a moment to talk about the developer’s lord and savior, Nix?
It’s a nice whirlwind tour of a lot of the issues you’ll hit if you try to do this, and a preview of some viable solutions. I really wish I had read this 2 years ago.
I work in the embedded sphere where everything is statically linked. And damn, things are a lot easier. I’m really liking the idea that if the binary size isn’t insane, deploy a static binary where possible. If you can, build libraries with
-ffunction-sectionsand the linker can remove sections that aren’t referenced.Added bonus: you may not have to build the code on the target system.
Excuse me, do you have a moment to talk about the developer’s lord and savior, Nix?
Other than whining, what’s the point of this article?
It’s a nice whirlwind tour of a lot of the issues you’ll hit if you try to do this, and a preview of some viable solutions. I really wish I had read this 2 years ago.