[fpc-devel][fpc-deve] fpc sparc port.
seyko at comail.ru
Tue Dec 3 12:15:19 CET 2002
You wrote to <fpc-devel at deadlock.et.tudelft.nl> on Tue, 3 Dec 2002 10:24:58
SK> In Linux DLL (*.so) can be made without PIC. In most cases this is
SK> even more preferable -- this DLL use less RAM. PIC may be needed
SK> only for glibc.so -- a wide used by _different_ programs DLL, in which
SK> case PIC give us a RAM saving. Reason: DLL in PIC format is bigger. If
SK> it not wide used (plugin for the only _one_ program ) -- we lost RAM
SK> and time if we use PIC format.
JM> Isn't PIC also necessary to support versioning? If you don't use PIC
JM> and you change a library, don't all programs that use that library have
JM> to be recompiled?
If we change a library (but not the interface of exported functions). then
we do not need to recompile any program. Versioning in Linux (glibc)
is supported by special option to linker: a list of function names which are
in each version of library
SK> Conclusion: there is a big need in DLL support even without PIC.
SK> Why not implement generation of DLL and use of it with
SK> FPC made main program under Linux without PIC?
JM> If you use the "library" keyword, we already generate a .so file
JM> without PIC code, so I'm not sure what the problem is (I haven't tested
JM> such libraries rigorously, but simple ones seem to work).
Thry to link FPC-produced main program with FPC-produced *.so
library. In such case we can get a trap because insteed of calling
init code in library (if we have initialization section for some library
we call main code initialization again.
With best regards, Sergey Korshunoff
More information about the fpc-devel