[fpc-devel]Last compiler source

[Pavel V. Ozerski]

>>1) also in t_win32 the old problem presents: parameter list of
>>FindObjectFile was changed but lines 908, 910 (inside
>>PAVEL_LINKLIB conditional block) were not fixed.
>
>Can you send me a patch ?
>

907:  if isdll then
908:   LinkRes.AddFileName(GetShortName(FindObjectFile('wdllprt0','')))
909:  else
910:   LinkRes.AddFileName(GetShortName(FindObjectFile('wprt0','')));



>   The main problem is that
>external name 'ANY_bizaRRE_nAMe';
>is translated into the whole compiler into an assembler label that is exactly
>'ANY_bizaRRE_nAMe'
>but your version of linklib associates
>external name 'DLLFunction';
>to the assembler label _DLLFunction
>with a leading underscore.

Please send me an example which could demonstrate this difference.

My example will be translated into the same asm code by both compiler variants:

{$linklib anylib}
function testfn(x:longint):pointer;
 external name 'testfn';
var
 p:pointer;
begin
 p:=testfn(1000);
 writeln(longint(p));
end.


	.file "test0.pp"

.text
	.balign 16
.globl	_main
_main:
.globl	PASCALMAIN
PASCALMAIN:
.globl	program_init
program_init:
	pushl	%ebp
	movl	%esp,%ebp
	subl	$4,%esp
	call	FPC_INITIALIZEUNITS
	pushl	$1000
	call	testfn
	movl	%eax,_P
.L7:
	leal	U_SYSTEM_OUTPUT,%edi
	movl	%edi,-4(%ebp)
	pushl	_P
	pushl	-4(%ebp)
	pushl	$0
	call	FPC_WRITE_TEXT_SINT
	pushl	-4(%ebp)
	call	FPC_WRITELN_END
	pushl	$.L7
	call	FPC_IOCHECK
	call	FPC_DO_EXIT
	leave
	ret
	.balign 16

.data
	.ascii	"FPC 1.1 [2000/11/20] for i386 - WIN32"
	.balign 4
.globl	FPC_RESOURCESTRINGTABLES
FPC_RESOURCESTRINGTABLES:
	.long	0
.globl	INITFINAL
INITFINAL:
	.long	1,0
	.long	INIT$$SYSTEM
	.long	0
.globl	HEAPSIZE
HEAPSIZE:
	.long	262144

.data

.data

.section .bss
	.lcomm	_P,4
	.comm	HEAP,262144


In this example is assumed that the external function, testfn, is located in dynamic library (e.g., dll for win32).

To link a static library created by ar GNU (or compatible) utility (.a, .aw etc), my version supports directives
like {$linklib anylib,static}. "Official" $linklib does not see differences between dynamic and static libraries.
It applies to both types of libraries the same command in linker response file:

INPUT(
-llibname
)

This assuming causes some problems. 1) default library extension used by ld is not always the same that used
in fpc (e.g., for win32 the static libraries are *.aw, but ldw waits for *.a); 2) Very often the big static libraries
contain cross-references and therefore they must be linked as a group; 3) The libraries search path written
in .res file does not contain current directory and therefore the linker cannot find third-party libraries if progammer
places them into his working directory.

The underscoring symbol (which must be added manually to externals names which are located in dll although really this
character is missed in this dll: external name '_MessageBoxA') is a forced and temporary solution. The cause is follow:
to "link" dll to exe, an interface static library must be created. Now this library is creating by dlltool which is developed for
C and therefore adds additional underscores. But one half of this work now is already moved to fpimpdef which creates
a .def file. It is possible, to develop fpimpdef to fpimplib which will generate ar-compatible COFF static libraries without
useless underscores. I could try to do it later.

Pavel