[gme-users] Using static libraries with GME interpreters

[Peter Volgyesi]

If you need to distribute 3rd party dlls (which are not distributed by
GME*), I suggest you to create a windows install package. It will save you
from stupid mistakes.
The other part of the question is rather tricky. In some cases it is
(almost) unavoidable to use multiple versions of the same dll in a given
process (eg.: if you're building an interpreter with VC7.1, it will depend
on mfc71.dll while GME still uses mfc42.dll). In theory it looks like a
disaster, however in practice this worked so far without any noticeable
errors. I don't have a clear answer here.  I would not like to include other
dlls in the GME release, which are not needed directly by GME.

(*) Currently, we are redistributing the following merge modules and dlls:
ATL.MSM (ATL3.0)
MFC42.MSM (MFC 6.0)
MSVCRT.MSM (Microsoft C Runtime Library 6.0)
MSVCP60.MSM (Microsoft C++ Runtime Library 6.0)
MSVCIRT.MSM (Microsoft C Runtime Library I/O 6.0)
COMCAT.MSM (Microsoft Component Category Manager Library)
MDAC27ENU.MSM (Microsoft Data Access Components 2.7, English)
OLEAUT32.MSM (Microsoft OLE 2.40 for Windows NT and Windows 95)

Harness_1_7_0.dll, Xalan-C_1_7_0.dll, XalanMessages_1_7_0.dll (Xalan 1.7)
xerces-c_2_4_0.dll (Xerces 2.4)

--
peter


> -----Original Message-----
> From: gme-users-bounces at list.isis.vanderbilt.edu 
> [mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf 
> Of Jonathan M. Sprinkle
> Sent: Friday, July 02, 2004 10:46 PM
> To: gme-users at list.isis.vanderbilt.edu
> Subject: Re: [gme-users] Using static libraries with GME interpreters
> 
> > > If a user is creating two or more interpreters for her
> > application, it
> > > is quite plausible that some of the overlapping code could
> > be placed
> > > in a static library and linked against the other two interpreters.
> > 
> > Wouldn't having object files as a static library cause 
> duplication in 
> > the two interpreters? Did you mean dynamic libraries?
> 
> I don't mind code duplication as the interpreters exists, as 
> much as I mind code duplication during compilation. :)
> 
> Dynamic libraries might be a better solution for some tasks, 
> but static libraries is as good as any for me for right now. 
> For one reason, if I use dynamic libraries, then I would have 
> to distribute multiple dlls for one interpreter.
> 
> Furthermore, I suspect that as a non-maintained project, it 
> is more beneficial to have one version of the dll than to try 
> to ensure that multiple versions of the common dlls can work 
> together, and shipping multiple versions of dlls as updates. 
> Relinking to get updated versions shouldn't take much time, 
> and as the software evolves, I am sure that there will be 
> updates done to the libraries as well.
> 
> Does this make sense? Does anyone (read: Peter,Adi) know 
> about the difficulties/benefits of having multiple .dlls for 
> an interpreter?
> 
> Thanks,
> Jon
> 
> _______________________________________________
> gme-users mailing list
> gme-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users