Hi,

Attached is a patch for the Makefile.fpc (and makefile) for the fcl/fpcunit directory. After applying the testdecorator unit is also installed and cleaned.

Regards,
Vincent.

Hello all,

1) I tried now to build a dll with {$smartlink on} using 1.9.9 compiler built at beginning of April. The created DLL did not contain export names. An analysis of generated asm code pointed that although a global label at beginning of .rva-containing asm-file has been correctly created but the PASCALMAIN module did not contain a reference to this label. At result, all EDATAs sould be eliminated at linking stage.

2) Because I braced up, to write this letter :), I would also report a old problem which I got using an old 1.1 FreeBSD port. I needed to build a shared UDF library for MySQL. While loading created .so file, I got an error message - something like "main entry point not found". An analysis of asm code demonstated that global main function mas named not "main" but had a name combined from a shared module name and "_main", therefore the dynamic linker could not find main entry point. At that time I solved this problem editing the asm code but this way seems to be not normal.

Sincerely, Pavel

Maybe a problem with binutils. The stripping of .stabs sections ("ld -s" or using strip) is also broken with recent binutils. We can't use old binutils since they can't link with recent cygwin libraries.

Since the problem is not in FPC code we can't fix it.

Hello Peter,
PV> Since the problem is not in FPC code we can't fix it. I'm not sure that you are right. There were a solution found that was based on a code generated by compiler. An asm/obj module with PASCALMAIN conained a reference to a label which was located in an asm/obj module contained export data section. In current compiler, this label creating is supported but a creation of the reference from PASCALMAIN module is lost. Additionaly, I use ld version 2.15.91 20040904.

Hello Peter,
PVO> I'm not sure that you are right. There were a solution found that I can explain that reported smartlink problem is not a binutils problem. I fixed generated asm code and got correct dll.

EDATA module:
**************

.section .bss

.section .edata
.globl _$PROGRAM$_L1
_$PROGRAM$_L1:
.long 0
.long 0
.short 0
.short 0
.rva .L26
.long 1
.long 2
.long 2
.rva .L27
.rva .L28
.rva .L29
.L26:
.ascii "CRPLUGIN.dll\000"
.balign 4,0
.L27:
.rva P$CRPLUGIN_MODULEPROC$LONGINT$TMAP$PCHAR$LONGINT$LONGINT$LONGWORD$LONGWORD$$LONGBOOL .rva P$CRPLUGIN_MODULEDATAMODE$$LONGINT
.balign 4,0
.L28:
.rva .L30
.rva .L31
.balign 4,0
.L29:
.short 1
.short 0
.balign 4,0
.balign 2,0
.L30:
.ascii "ModuleDataMode\000"
.balign 2,0
.L31:
.ascii "ModuleProc\000"

Non-patched PASCALMAIN module:
**************
.section .text
.balign 4
.balign 4
.globl PASCALMAIN
PASCALMAIN:
.globl _P$CRPLUGIN_main
_P$CRPLUGIN_main:
pushl %ebp
movl %esp,%ebp
call FPC_INITIALIZEUNITS
leave
ret
.balign 4

Fixed PASCALMAIN module:
************
.section .text
.balign 4
.balign 4
.globl PASCALMAIN
PASCALMAIN:
.globl _P$CRPLUGIN_main
_P$CRPLUGIN_main:
pushl %ebp
movl %esp,%ebp
call FPC_INITIALIZEUNITS
leave
ret
.long _$PROGRAM$_L1
.balign 4

Hello all,

I found something that explains a loss of reference from PASCALMAIN module to edata module. In pmodules.pas, in proc_program procedure an inserting of this reference is provided.

if assigned(exportlib) and
(target_info.system in [system_i386_win32,system_i386_wdosx]) and assigned(current_module._exports.first) then

But actually current_module._exports.first is nil (at least at this stage). The condition is false, inserting doesn't occur.

Pavel

Hello all,

It seems, I solved the smartlink problem.
Solution:
1) in pexports.pas, I added into interface part of unit

    var
      BinaryContainsExports: boolean = false;

2) in pexports.pas, in first line of main body of read_exports procedure, I added
....

      begin
         BinaryContainsExports:=true; //NEW!!!
         DefString:='';

....
3) in pmodules.pas, I added a reference to pexports into the uses clause of implementation part.

4) in pmodules.pas, I changed a line in proc_program procedure: INSTEAD
if assigned(exportlib) and
(target_info.system in [system_i386_win32,system_i386_wdosx]) and assigned(current_module._exports.first) then

           codesegment.concat(tai_const.create_sym(exportlib.edatalabel));

I MADE
if assigned(exportlib) and
(target_info.system in [system_i386_win32,system_i386_wdosx]) and BinaryContainsExports then

           codesegment.concat(tai_const.create_sym(exportlib.edatalabel));

That's all. The patched compiler builds my tests correctly.

Hello FPC Team,

Please explain me why my yesterday's work remained be ignored? Practically, I think, I solved a problem at fixed a bug. Are you discordant with my way of solution or are waiting for diff?

Pavel V. Ozerski wrote

Please explain me why my yesterday's work remained be ignored? Practically, I think, I solved a problem at fixed a bug. Are you discordant with my way of solution or are waiting for diff?

Probably nobody has had time yet to in mind that FPC is our spare time project.

Jonas

No time, we all have other jobs. Providing a complete diff helps. It can be verified quicker.

Hello Peter,

Thursday, April 28, 2005, 11:37:30 AM, you wrote:

PV> No time, we all have other jobs. Providing a complete diff helps. It can PV> be verified quicker.

I see a potential problem i my yesterday's solution. Now I use an initialized variable (or typized constant) which changes its value at run-time. That is good while compiler compiles only one application (e.g. from the command line). But if compiler will compile more than once at run-time (e. g. it will be a dll called from IDE), all such flag variables should be re-initialized before next job. Currently no re-initialization is provided in my path. Is this re-initialization really actual?