While I don't quite understand the specifics the author describes, I can relate very well to the general problem: Open Source software often depends on packages that are common on the Linux Desktop. This quickly gets you into dependency hell if you try to compile the program/library on a different platform.
An example I was recently confronted with was libmdb, a library that reads Microsoft Access databases. For some reason it depends on glib2, which in turn depends on a few other libraries. In the end I needed to compile 5 different libraries because libmdb uses hash tables and arrays from glib2.
The alternative would be for libmdb to implement that stuff themselves. That would increase development time, increase the amount of bugs, increase the size and decrease developer happiness.
Or they could link statically. They're both under the LGPL, and it seems like the sensible thing to do if they're only using the library for hash tables...
The project authors certainly don't care about people with 'special' requirements. For them it just saves time.
Now the packagers _could_ do what you suggest, but especially for such a central library it doesn't make sense. You want to have only one version of that thing for a gazillion reasons.
The original request for this thread? Well, it seems that person wanted to port a library to a completely different system _and created the binary for that system_. Right, he can statically link it. What does he gain? He still needs to gather all dependencies before and his complaint (as a developer/distributor) of having to meddle with glib would be the same. He didn't complain about distributing another couple .so files as far as I understand the issue.
I suppose he meant, as opposed to standard compliant libraries. For hash tables there's search.h for example. But there might obviously be other reasons like feature set and so on to pick a different library.
How is modularization and code reuse a bad thing? Fortunately, both source and binary distributions are great when it comes to dealing with dependencies.
False dichotomy. Libraries that provide basic data structures should not have external dependencies. The issue isn't whether or not to use libraries, it is how the functionality of the libraries is organised.
An example I was recently confronted with was libmdb, a library that reads Microsoft Access databases. For some reason it depends on glib2, which in turn depends on a few other libraries. In the end I needed to compile 5 different libraries because libmdb uses hash tables and arrays from glib2.