Date:	Fri, 20 May 94 14:38:31 +0200
From:	vincent AT physique DOT ens DOT fr (CROQUETTE Vincent)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu

	DLL versus DLD

	DLL appears to be quite different from DLD: 

	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.  


	DLL apparently works the other way round you have first
to link f2.o and then you link f1.o because any undefined
symbol will causes an error. You can "register" external
symbol but then you have to link them with the calling
program. This mean that the calling program must be build
according to the DLL and if you modify the DLL and, for
instance add the sin() function and this is not link in the
caller you must recompile the caller. The only turn arround I
have sought is to link the sin.o module before linking the
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!


	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?


	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
suprise the size of the stub is quite big : here follow an
example with liblug

	LIBLUG  .A      118366 08.01.94   13:02
	libLUG	.O       83418 17.05.94    8:39
	LLUGdll	.S       72551 17.05.94    8:41
	LLUGdll	.O       55063 17.05.94    8:44

	libLUG.O + LLUGdll.O is bigger that the original LIBLUG
.A

	
	
	Am I misunderstanding the readme
	
	vincent croquette

- Raw text -