Date:	Fri, 20 May 94 10:30:12 -0400
From:	dj AT ctron DOT com (DJ Delorie)
To:	vincent AT physique DOT ens DOT fr
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

> 	DLL appears to be quite different from DLD: 

Yup.  DLL is djgpp-specific and not gpl.

> 	in DLD if f1.o needs f2.o to works, you can link f1.o by
> dld_link(f1.o) and  then you link f2.o by dld_link(f1.o), you
> check for undefined symbols and if none and if the function
> is executable you execute it. Futhermore you can link a
> standart library where DLD will get only the modules it
> lacks.  

So what you're saying is that you should be able to load an object and
delay complaining about unresolved symbols until after you load some
other objects?

> caller you must recompile the caller. The only turn arround I
> have sought is to link the sin.o module before linking the

Or make libc.a a DLL (same for libm.a etc)

> new DLL. The trouble comes if you have more than one DLL :
> did the previous one link also sin.o for instance? here there
> is a small bug, DLL does not complain for duplicate symbols!

Not a problem, because it only calls it's own symbol.

> 	Am I wrong when I say that mkdlo.bat <library.a>
> <dll_object.o> build an objet where all modules are going to
> be linked regardless of being referenced?

Currently.  The ideal case would be to have dll be able to load from a
library directly as needed.

> 	Finally I like the idea of stubing a DLL like in autotest
> however there is a small bug if the true libgr.o is not in
> the PATH you get "segmentation violation". I have also a

Probably.  The dll code is little tested.

> suprise the size of the stub is quite big : here follow an
> example with liblug

That's because it stores the *name* of *each* symbol in the file.
This is usually a large percent of the original library.  Shared
libraries store the actual offset, but then you must use the right
version of the library each time.

- Raw text -