41–50 of 136 posts
.so .o .a .pc holy shit, what a mess Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system
> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…
We already had scripting engines for those languages in the 1990's, and the fact they are hardly available nowadays kind of tells of their commercial success, with exception of ROOT.
> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…
Yes, these are really esoteric options, and IIRC GCC's docs say they can be counter-productive.
Earlier quoted context omitted.
> Static libraries have lots of game-changing advantages, but performance, security, and portability are the biggest ones. No idea how you come to that conclusion, as they are definitively no more secure than shared libraries. Rather the opposite is true, given that you (as end user) are usually able to replace a shared library with a newer version, in order to fix security issues. Better portability is also question…
I think from a security point of view, if a program is linked to its library dynamically, a malicious actor could replace the original library without the user noticing, by just setting the LD_LIBRARY_PATH to point to the malicious library. That wouldn't be possible with a program that is statically linked.
.so .o .a .pc holy shit, what a mess Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system
Because those other ecosystems assume that someone has already done the work on the base system and libraries that they don't have to worry about them, and can focus purely on their own little islands.
Note that ISO C and ISO C++ ignore the existence of compilers, linkers and build tools, as per legalese there is some magic way how the code gets turned into machine code, the standards don't even consider the existence of filesystems on header files and translation units locations, they are talked about in the abstract, and can in all standard compliant way be stored in a SQL database.
Earlier quoted context omitted.
I routinely tear apart badly laid-out .a files and re-ar them into something useful. It's a few lines of bash.
This works, but scripting with the ar tool is annoying because it doesn't handle all the edge cases of the .a format. For instance if two libraries have a source file foo.c with the same name, you can end up with two foo.o, and when you extract they override each other. So you might think to rename them, but actually this nonsense can happen with two foo.o objects in the same archive . The errors you get when running…
but for your trouble: https://gist.github.com/b7r6/0cc4248e24288551bcc06281c831148...
If there's interest in this I can make a priority out of trying to get it open-sourced.
.so .o .a .pc holy shit, what a mess Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system
This is such an ignorant comment.
Most other natively compiled languages have exactly the same concept behind: Object files, Shared Libraries, collection of object and some kind of configuration description of the compilation pipeline.
Even high level languages like Rust has that (to some extend).
The fact it is buried and hidden under 10 layers of abstraction and fancy tooling for your language does not mean it does not exist. Most languages currently do rely on the LLVM infrastructure (C++) for the linker and their object model anyway.
The fact you (probably) never had to manipulate it directly just mean your higher level superficial work never brought you deep enough where it starts to be a problem.
.so .o .a .pc holy shit, what a mess Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system
> Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system This is such an ignorant comment. Most other natively compiled languages have exactly the same concept behind: Object files, Shared Libraries, collection of object and some kind of configuration description of the compilation pipeline. Even high level languages like Rust has that (to some extend). The…
Did you just agree with me that other prog. ecosystems solved the building system challenge?
Earlier quoted context omitted.
This works, but scripting with the ar tool is annoying because it doesn't handle all the edge cases of the .a format. For instance if two libraries have a source file foo.c with the same name, you can end up with two foo.o, and when you extract they override each other. So you might think to rename them, but actually this nonsense can happen with two foo.o objects in the same archive . The errors you get when running…
`boost` is a little sticky too: https://gist.github.com/b7r6/e9d56c0f6d55bc0620b2ce190e15d44... but for your trouble: https://gist.github.com/b7r6/0cc4248e24288551bcc06281c831148... If there's interest in this I can make a priority out of trying to get it open-sourced.
I feel like we really need better toolchains in the first place. None of this intrinsically needs to be made complex, it's all a lack of proper support in the standard tools.
> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…
How can they be expected to learn this, when it is now fashionable to treat C and C++ as if they are scripting languages, shipping header only files? We already had scripting engines for those languages in the 1990's, and the fact they are hardly available nowadays kind of tells of their commercial success, with exception of ROOT.
It's the first thing Google and LLMs 'tell' you when you ask about reducing binary size with static libraries. Also LTO does most of the same.