[dozzie]

> All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that [...]

It's not something to regularly rely on, but something that helps in debugging and troubleshooting. Not for a programmer, but for a sysadmin.

> Having shared objects on the machine actually makes this impossible because your tests are running with different libraries than in production.

In such a case you have your deployment process broken. And if your testing and production environments differ in this matter, they differ enough bite your ass even with your statically linked binary.

> Shared libraries on a machine are a non-hermetic input to your build and are to be avoided.

This is merely stating a generic opinion. I want to see a concrete, coherent, technical argument supporting this.

> In addition, runtime shared objects (especially of something performance-critical like crypto) inhibit all of the most important compiler optimizations like inlining.

Especially crypto should not be called in a tight loop, but passed a large chunk of data. Otherwise you inhibit all of the most important defence against side channel attacks, and I guarantee that you are not competent enough to defent against that on your own.

> As for ltrace, there's a million ways to trace function calls these days, like uprobe or perf.

So let's break one of them for no good reason?

And still, lack of any of the mentioned things is merely an annoyance once you hit it, but as I said, they are numerous and add up, while the other option, static linking, provides little benefit apart from supporting broken workflows (like different environment in testing and production).