Hello together!

After the previous thread about packages I experimented a bit more with them.

I tried to compile the following package:

==== source begin ====
package rtl;
contains
   system;
end.
==== source end ====

The system unit was precompiled by me for Win32 and for Linux.

The following call was used for Linux:

pp -Fuunits/i386-linux rtl.ppk

and the following for Windows:

pp -Twin32 -Fuunits/i386-win32 rtl.ppk

For Linux I needed to apply the following patch to the compiler to reach linking stage:

==== patch begin ====

Index: compiler/expunix.pas
=================================================================== --- compiler/expunix.pas (Revision 16005)
+++ compiler/expunix.pas (Arbeitskopie)
@@ -142,6 +142,7 @@

    while assigned(hp2) do
     begin
       if (not hp2.is_var) and

+ (assigned(hp2.sym)) and
(hp2.sym.typ=procsym) then

        begin
          { the manglednames can already be the same when the procedure

==== patch end ====

And now I get a linking error, because the exports of the package are added as an import library. Thus the package tries to import itself which fails on Linux. With target win32 it works, but an objdump shows this:

==== output begin ====

00025028 00025158 00000000 00000000 00025734 00025264

DLL Name: rtl
vma: Hint/Ord Member-Name Bound-To
256c4 3 FPC_WIDEINITTABLES

==== output end ====

The source of the problem seems to be in pmodules line 1960 where "createimportlibfromexports" is called.
Removing this call results in a linking error on Win32 (FPC_WIDEINITTABLES not found) and on Linux in library.

The Windows package is created as "rtl.dll" and the Linux one as "librtl.so", although I expected "rtl.ppl" for Win32 and "librtl.ppl" for Linux or even "rtl-2.5.1.ppl" and "librtl-2.5.1.ppl" on the respective platforms. So this needs to be fixed as well.

I then tried to compile the following sample program for Linux, but it also required the units "si_prc" and "fpintres" which I compiled manually then:

==== source begin ====

program test;
begin
   Write('Hello World');
end.

==== source end ====

As long as "system.o" was still in the units directory FPC just linked that in. Once I renamed it the compiler (or better: the linker) complained about it missing. So the compiler might not yet check whether a shared lib name was inserted in the ppu? Or does it use the system.o if it can not find the shared lib? (because in system.ppu it's named "imprtl")

I then added "-k-lrtl -st" to FPC's command line and removed the "system.o" from the "test_link.res". Calling test_ppas.sh resulted in the following output:

==== output begin ====

Linking test
ld: warning: test_link.res contains output sections; did you forget -T? test.o: In function `main':
test.pas:(.text+0xa): undefined reference to `FPC_INITIALIZEUNITS' test.pas:(.text+0x27): undefined reference to `FPC_IOCHECK' test.pas:(.text+0x33): undefined reference to `FPC_IOCHECK' An error occurred while linking test

==== output end ====

Those two symbols are indeed missing in librtl.so (but FPC_LIBINITIALIZEUNITS is included), so something didn't work quite right here.

So much for my findings. I hope you find it interesting. :)

Regards,
Sven

Hi Sven!

Sven Barth wrote

and the following for Windows: pp -Twin32 -Fuunits/i386-win32 rtl.ppk

I tried this with my 64 bit-head version of fpc, but it failed to produce any output except an .a and an .o file.

fpc -Twin64 -Fuunits\x86_64-win64 rtl.ppk
unknown: 12
unknown: 12
rtl.ppk(7) Error: PPU is already in a library :
C:\source\fpcwilli\units\x86_64-win64\rtl\system.ppu rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN
rtl.ppk(7) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted
Error: C:\source\fpcwilli\bin\x86_64-win64\ppcx64.exe returned an error exitcode (normal if you did not specify a source file to be compiled)

So I guess there's more work to be done on the win64 target: I will look into this once I have a debug build of trunk (see my other mail) on my disk.

The Windows package is created as "rtl.dll" and the Linux one as "librtl.so", although I expected "rtl.ppl" for Win32 and "librtl.ppl" for Linux or even "rtl-2.5.1.ppl" and "librtl-2.5.1.ppl" on the respective platforms. So this needs to be fixed as well.

True we also need to implemente the $LIBSUFFIX and $LIBVERSION (probably also $DESCRIPTION) compiler switches..

So much for my findings. I hope you find it interesting. :)

Thanks a lot. I found the differences between Linux, Windows32 and Windows64 (my own build) interesting to see. Yep, there's quite some work ahead.. That said, I'll probably concentrate on Win64 first as I am running Windows 7 x64.

BTW: Is it possible to get a separate branch in the svn repo for hacking on the package feature? Or should source-code patches be posted to fpc-devel before directly going into trunk?

Cheers,
Willi

Try the following:

- create a new test directory (I'll call it "c:\test" now)
- copy the following directories from FPC's source to "c:\test" (you can put them directly into that directory with a "rtl" dir):
- rtl\inc
- rtl\x86_64
- rtl\win
- rtl\win64
- create the directory "c:\test\units\x86_64-win64"
- open cmd and go to "c:\test"
- execute the following command:
fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64 win64\system.pp

Now you should have a system.ppu and a system.o in "c:\test\units\x86_64-win64". Now you create the rtl.ppk in "c:\test" and run the compiler using the following command:
fpc -Fuunits\x86_64-win64 rtl.ppk

Note: You need to recompile the system.pp once you've tried to compile the rtl.ppk or you'll get the error you mentioned.

If you have problems regarding this procedure, please don't hesitate to ask (but I might not be able to answer till Thursday, cause I'm on a developer conference).

Regards,
Sven

- execute the following command: fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64 win64\system.pp

Had to change it to

fpc -Us -Sg -Firtl\inc -Firtl\x86_64 -Firtl\win -Firtl\win64 -FUunits\x86_64-win64 rtl\win64\system.pp

but this worked, as expected.

Now you should have a system.ppu and a system.o in "c:\test\units\x86_64-win64". Now you create the rtl.ppk in "c:\test" and run the compiler using the following command: fpc -Fuunits\x86_64-win64 rtl.ppk

This did not work:

....> type rtl.ppk
package rtl;
contains
   system;
end.

....> fpc -Fuunits\x86_64-win64 rtl.ppk
unknown: 12
unknown: 12
rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup rtl.ppk(7) Error: Undefined symbol: PASCALMAIN
rtl.ppk(7) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

If you have problems regarding this procedure, please don't hesitate to ask (but I might not be able to answer till Thursday, cause I'm on a developer conference).

Thanks! Well, I guess I have to get a debug-build of fpc first and then I'll probably have to investigate where the "unknown: 12" is coming from, etc..

Anyway, thanks for your help on this!

Cheers,
Willi

The conference departure got shifted by one day, so I can answer you today, but then not until Friday :P

This does indeed seem like a problem in the Win64 compiler cause the Win32 one is working (are you using the trunk version?)

You can compile and debug FPC from within Lazarus IDE. Just open compiler/pp.lpi (or maybe compiler/ppx86_64.lpi in your case) and compile it (for 2.5.1 you need a 2.4.0 as compiler for the compiler).

Regards,
Sven