Message-ID: <006701c2a887$86708e90$0100a8c0@p4>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>
References: <10212200707 DOT AA24651 AT clio DOT rice DOT edu>
Subject: Re: LibC loaded Dynamically
Date: Sat, 21 Dec 2002 11:25:23 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1123
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123
Reply-To: djgpp-workers AT delorie DOT com

> But we would need to support both static and dynamic link libraries,
> and what about libm, libgcc, libiconv?  It's a huge shift in
> development and philosophy.  It could make libc updates much more
> difficult to maintain backward compatibility.
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.

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.

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.

 Regards,
Andrew