So is using binary packers like UPX. Not just will they sound the alarm in a lot of so called security products, but they'll also prevent the operating system f

So is using binary packers like UPX. Not just will they sound the alarm in a lot of so called security products, but they'll also prevent the operating system from sharing the RAM used to mmap() read-only and read-execute pages from the executable while increasing startup times. Removing random sections will also cause headaches when it comes to tracing and debugging in production. Just accept that those sections fulfil real world requirements and aren't just shiny nerd knobs for knobs to mess with. If your code isn't worth being traceable/debuggable in production it's not worth having it installed on production servers. Also don't go too far with the build flags or you risk waking the sleeping horrors lurking in the seldom tested dark corners of the compilers and linkers we all rely on e.g. accidentally changing the effective ABI through tricks like smaller enums. Some of those bugs may only trigger on certain architectures e.g. exception handling works differently on amd64 and aarch64. On one of the two uses special an extra section to locate the unwind helpers. Do you know the all implications of removing a section from an executable? sigh Please keep bloat down, but eager developers shouldn't too far beyond the point of quickly diminishing returns within a given ecosystem they're targeting.