From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10212220353.AA21709@clio.rice.edu>
Subject: Re: LibC loaded Dynamically
To: djgpp-workers AT delorie DOT com
Date: Sat, 21 Dec 2002 21:53:17 -0600 (CST)
In-Reply-To: <006701c2a887$86708e90$0100a8c0@p4> from "Andrew Cottrell" at Dec 21, 2002 11:25:23 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> When upgrading to the latest FSF code in general the update in most cases
> uses libiconv  and sometimes a few other additional libraries which then
> causes the exe to double in size or in some cases blow out by 1MB.

The current WIP dxe stuff, and the DXE3/dlopen() package both handle this.
So I'm sure we will finalize something relatively soon.  It's a matter of
complexity, dlopen() compatibility, backward compatibility, and overhead 
in the image to use it.

We've pretty much concluded that one size doesn't fit all, but we'd like
them to be consistent (with common core components, if we can resolve the
incompatibilites...).  What Daniel calls dxe3res and I call dxe2obj both
make calling the DXE transparent (you link to a library which contains
symbols, and that module loads the DXE for you).

It appears constructors, destructors and exception frames all work.  We
are discussing how flexible this stuff should be (should it be linux
_init compatible, or easier to use?)

> My 2 cents worth is:-
> a) I would like to see the "support" libraries as dynamick link libraries as
> they shouldn't change that often and are already shared libraries on Linux,
> so hopefully they should be easier to get working and porting.

This is easy, but we need to get the distribution packages to support 
building it out of the box ...  Which means a standard package.

> I am in the process of updateing a program for work that I have been adding
> functionality to for over 3 years now and have just had to add more Allegro
> code to the cut down allegro library I use. I use a cut down version so that
> the resulting exe is small, but this has the down side that I do not track
> the changes and enhancments/bug fixes in the main Allegro code becuase it is
> to big. I suspect that the work being done by Charles will help me out a
> great deal when it is released and I have time to modify my application. The
> app is a comms decoder for checking comms in the gaming industry.

I don't think anyone's put Allegro in a DXE yet, but I don't expect any
problems (see the announcement on Python for hints on what's possible).
I'm not bugging people yet because the DXE format may change between the
current stuff and the final release.