Date: Thu, 30 Oct 1997 20:24:18 -0800 (PST)
Message-Id: <199710310424.UAA26558@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Peter Palotas <blizzar AT hem1 DOT passagen DOT se>,
        "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: Dynamic Linked Libraries for djgpp?
Cc: djgpp AT delorie DOT com
Precedence: bulk

At 10:12  10/30/1997 -0500, Peter Palotas wrote:
>At 14.45 1997-10-30 +0000, you wrote:
>>> Are there some "DLL"'s that is supported by GCC on UNIX?  Or some
>>> equavilent thing that is standard on UNIX systems?
>>
>>Yes, gcc (ld to be more exact) can generated dynamically linked libraries,
>they 
>>are much more powerful than the (dead brain) M$ DLL idea. 
>>This helps in too aspects: saves disk space and saves memory.
>
>Is this not included in the DOS port of gcc (i.e. DJGPP if somebody should
>have accidently missed that)? And in that case why? (If not, where, how??)
No... you can certainly configure the binutils to output any kind of object
file you want, including ELF. So from that standpoint, it is possible to
create a shared library. BUT... for starters, DJGPP is very heavily based on
COFF. Using anything else would require a significant rewrite of at least
the stub, the debugging library, and probably a good piece of the startup
code. Also, DJGPP does not have the dynamic library loader that is necessary
when you use shared libraries. (Something has to resolve all those externals
and point things to all the right places.) It may happen in the distant
future, but it would be a *lot* of work. Furthermore, I'd guess that on DOS,
a system without a way to keep the shared libraries loaded into memory,
you'd get *much* longer load times when the whole C library had to be loaded
from disk each time you ran a file. A disk cache would help, but how much?...

It's definitely not an omission, just a very difficult feature to implement.

Nate Eldredge
eldredge AT ap DOT net