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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
