Q: Many other compilers use shared libraries and DLLs to make the
programs' size smaller; why don't you do the same?
A: DLLs are really a mixed blessing, because they introduce an additional dimension into configuration management and subtle system differences.
Consider a DJGPP developer who is maintaining a package. Let's say that this developer finds a bug in one of the library functions that adversely affects his/her package. The obvious solution is to fix the library bug, and then relink the application against the fixed library. In the current setup, the only thing that the developer needs to do is to upload a binary distribution with the new executables, which will ensure that all users can reliably use the fixed program.
Now imagine that we ditch the static linking and instead distribute the standard libraries as DLLs to be installed on every machine. Our developer will now need to put a fixed DLL into the binary distribution, otherwise the package will still exhibit the bug when it uses an old DLL on the end-user's machine. Installing the fixed package would then need to overwrite the DLLs on users' machines with the fixed version.
But now suppose that the bugfix in that single library function made it subtly incompatible with other library functions, which the program of our developer didn't use (and so these problems went unnoticed during testing). When users will install the fixed DLL, they will now have a broken system, where programs which are unrelated to the upgraded package, and which worked perfectly before, would now mysteriously fail or crash.
Moreover, since there are quite a few DJGPP packages, all maintained separately by different individuals, and since users are installing the new-and-improved versions all the time, after some time there's no way to know what versions of system DLLs are installed on any given machine. The result is that no developer can be sure that their programs would work on any particular system, because the precise mix of the system DLLs on that system cannot be predicted. What you have is an environment where major programs constantly crash.
Sounds familiar? Of course! this is precisely the reason that most Windows systems are so unstable: people are constantly installing the hottest new versions of Office, IE, etc., and are constantly overwriting their system DLLs with new and subtly incompatible versions. If you can afford it, try to install Windows 9X and run it for a year without installing any add-on packages which come with a replacement for system DLLs--you will see a rock-solid system that can be run for weeks without crashing. (Yes, I actually tried that; yes, it really didn't crash.)
In addition, DLLs in the DJGPP environment make much less sense than on Unix or Windows, because the DJGPP DLLs will only be used by DJGPP program, whereas Unix shared libraries and Windows DLLs are used by the OS itself as well. When the OS itself uses the same libraries, the libraries are most of the time in memory when the applications need them, and running several applications only loads the library once. DJGPP cannot take advantage of this, even on Windows, because each DJGPP program runs in a separate Virtual Machine with a separate address space. The only case where DJGPP program can benefit from shared libraries is when one DJGPP program invokes another.
So bottom line, I think wasting some disk space due to static linking is much cheaper than having to deal with the user frustration and outcry that would result from using the DLL approach. Perhaps a behemoth such as Microsoft can afford ignoring all the mess that DLLs bring to the end users, but around here, a good name of the product still counts.