8 ms·
> 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 unu
by TuxSH 1y ago
> 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 the following logging module: (...)
Relying on static initialization order, and on runtime static initialization at all, is never a good idea IMHO
- deleted 1y ago[deleted]
- astrobe_ 1y agoYes, these are really esoteric options, and IIRC GCC's docs say they can be counter-productive.
- jeffbee 1y ago-ffunction-sections has 750k hits on github. It is among the default flags for opt mode builds in Bazel. There are probably people who consider them defaults, in practice.
- astrobe_ 1y agoWell, C and C++ together have around 7M repos, so about 10%. Actually not entirely esoteric, but Github is only a fraction of the world's codebase and users of these repos probably never looked in the makefile, so I'd say 10% of C/C++ developers knowing about this is a very optimistic estimate.
- wtallis 1y agoLooking at GitHub is probably significantly undersampling the kinds of C projects that would be doing static linking, many of which pre-date GitHub.
- readmodifywrite 1y agoOne engineer's esoteric is another's daily driver. All 3 of those options are borderline mandatory in embedded firmware development.
- TuxSH 1y agoThese options can easily be found by a Google Search or via LLM, whichever one prefers > they can be counter-productive Rarely[1]. The only side effect this can have is the constant pools (for ldr rX, [pc, #off] kind of stuff) not being merged, but the negative impact is absolutely minimal (different functions usually use different constants after all!) ([1] assuming elf file format or elf+objcopy output) There are many other upsides too: you can combine these options with -Wl,-wrap to e.g. prune exception symbols from already-compiled libraries and make the resulting binaries even smaller (depending on platform) The question is, why are function-sections and data-sections not the default? It is quite annoying to have to deal with static libs (including standard libraries themselves) that were compiled with neither these flags nor LTO.
- dmitrygr 1y agoEsoteric? In embedded, people know of these from BEFORE they stop wearing diapers
- pjmlp 1y agoHow 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.
- TuxSH 1y ago> How can they be expected to learn this 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.
- asveikau 1y agoIt makes more sense for c++ due to templates, but the header only C library trend is indeed very strange. It's not surprising that people are coming up now who are writing articles about being confused by static linking behavior.
- pjmlp 1y agoEven with C++ templates, if you want faster builds, header files aren't the place to store external templates, which are instantiations for common type parameters.
- TuxSH 1y agoHeader-only is simpler to integrate, so it makes sense for simple stuff, or stuff that is going to be used by only one TU there. However, the semantics of inline are different between C and C++. To put it simply, C is restricted to static inline and, for variables, static const, whereas C++ has no such limitations (making them a superset); and static inline/const can sometimes lead to binary size bloat
- greenavocado 1y ago> Do people really not know about $OBSCURE_GCC_FLAG? Do you know what you sound like?
- deleted 1y ago[deleted]
- alextingle 1y agoIf your whole business revolves around shipping static libraries to customers, then surely reading the man page to work out how that can be done is part of the job. Also, having your library rely on static initialisation doesn't seem like a very sound architectural choice. Honestly, this just sounds like whining from someone who can't be bothered to read the documentation, and can't get the coders to take him seriously. In the time it took him to write that article, he could have read up on his tools, and probably learned some social skills too.
- izacus 1y agoAnd do you know how you sound like when you call a well known, first hit on Google/AI, set of flags as obscure?
- flohofwoe 1y agoThere's also the other 'old-school' method to compile each function into its own object file, I guess that's why MUSL has each function in its own source file: https://github.com/kraj/musl/tree/kraj/master/src/stdio https://github.com/kraj/musl/tree/kraj/master/src/stdio ...but these days -flto is simply the better option to get rid of unused code and data - and enable more optimizations on top. LTO is also exactly why static linking is strictly better than dynamic linking, unless dynamic linking is absolutely required (for instance at the operating system boundary).
- pjmlp 1y agoOr plugins, or hotcode reload techniques, unless people want to go the OS IPC route that seems forgotten to many, while being safer, but naturally more resource demanding.
- viraptor 1y agohttps://xkcd.com/2501/ https://xkcd.com/2501/ ... It's easy to forget that the average person probably only knows two or three linker flags ...
- rurban 1y agoIt's heavily use in embedded only