Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2024-10

RTL make shared

7 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Adriaan van Os

Trying to build the FPC RTL as a dynamic library on MacOS (with make shared), I run into several problems

1. When I try with fpc-3.0.4 or 3.2.2, ppumove returns an ld error that -shared is an unknown flag. I think the ld flags -shared -E should be -dylib -dynamic on MacOS

2. When I do the linking pass by hand, ld complains about unknown symbols

ld: Undefined symbols:
FPC_RESLOCATION, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESOURCESTRINGTABLES, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESSTRINITTABLES, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_THREADVARTABLES, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o INITFINAL, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o _PASCALMAIN, referenced from:
_TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o __stklen, referenced from:
_SYSINIT_$$_FPC_SYSTEMMAIN$LONGINT$PPANSICHAR$PPANSICHAR in sysinit.o

Any help building a dynamic RTL is much appreciated.

Regards,

Adriaan van Os

Reply by email

Adriaan van Os
Show quoted text 5 lines
Trying to build the FPC RTL as a dynamic library on MacOS (with make shared), I run into several problems 1. When I try with fpc-3.0.4 or 3.2.2, ppumove returns an ld error that -shared is an unknown flag. I think the ld flags -shared -E should be -dylib -dynamic on MacOS

I forgot to mention - when I build with fpc-3.3.1 trunk I get an additional error that ppumove doesn't know the -P flag. Doing the link by hand, the ld unnown symbol errors remain.

Regards,

Adriaan van Os

Reply by email

Sven Barth
to Adriaan van Os: Trying to build the FPC RTL as a dynamic library on MacOS (with make shared), I run into…

Adriaan van Os via fpc-devel schrieb am
Di., 29. Okt. 2024, 11:29:

Trying to build the FPC RTL as a dynamic library on MacOS (with make shared), I run into several problems

I don't know when that was tested last in any platform...

Show quoted text 19 lines
2. When I do the linking pass by hand, ld complains about unknown symbols ld: Undefined symbols: FPC_RESLOCATION, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESOURCESTRINGTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESSTRINITTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_THREADVARTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o INITFINAL, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o _PASCALMAIN, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o __stklen, referenced from: _SYSINIT_$$_FPC_SYSTEMMAIN$LONGINT$PPANSICHAR$PPANSICHAR in sysinit.o

sysinit should be part of the program, not the library.

Regards,
Sven

Reply by email

Adriaan van Os
to Sven Barth
Sven Barth wrote 10 lines
Adriaan van Os via fpc-devel < > schrieb am Di., 29. Okt. 2024, 11:29: Trying to build the FPC RTL as a dynamic library on MacOS (with make shared), I run into several problems I don't know when that was tested last in any platform...

Thanks for the reply.

Isn't this related to library packages ?

Show quoted text 24 lines
2. When I do the linking pass by hand, ld complains about unknown symbols ld: Undefined symbols: FPC_RESLOCATION, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESOURCESTRINGTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_RESSTRINITTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o FPC_THREADVARTABLES, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o INITFINAL, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o _PASCALMAIN, referenced from: _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o __stklen, referenced from: _SYSINIT_$$_FPC_SYSTEMMAIN$LONGINT$PPANSICHAR$PPANSICHAR in sysinit.o sysinit should be part of the program, not the library.

The idea of building the RTL in a dynamic ibrary is to have one copy of the RTL threadvars, notably one copy of the _ExceptObjectStack threadvar. Will this still be true if a main program and a dynamic library both include sysinit.o ?

Regards,

Adriaan van Os

Reply by email

Sven Barth
to Adriaan van Os

Adriaan van Os via fpc-devel schrieb am
Di., 29. Okt. 2024, 15:47:

Show quoted text 16 lines
Sven Barth via fpc-devel wrote: > Adriaan van Os via fpc-devel < > > schrieb am Di., 29. Okt. 2024, > 11:29: > > Trying to build the FPC RTL as a dynamic library on MacOS (with make > shared), I run into several > problems > > > I don't know when that was tested last in any platform... Thanks for the reply. Isn't this related to library packages ?

No, not really. This is essentially forcefully moving code into a library and this only works on *nix platforms. With dynamic packages much more metadata is involved, because the runtime can then check whether packages are compatible.

Show quoted text 31 lines
> > > 2. When I do the linking pass by hand, ld complains about unknown > symbols > > ld: Undefined symbols: > FPC_RESLOCATION, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > FPC_RESOURCESTRINGTABLES, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > FPC_RESSTRINITTABLES, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > FPC_THREADVARTABLES, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > INITFINAL, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > _PASCALMAIN, referenced from: > _TC_$SYSINIT_$$_SYSINITENTRYINFORMATION in sysinit.o > __stklen, referenced from: > _SYSINIT_$$_FPC_SYSTEMMAIN$LONGINT$PPANSICHAR$PPANSICHAR in > sysinit.o > > > sysinit should be part of the program, not the library. The idea of building the RTL in a dynamic ibrary is to have one copy of the RTL threadvars, notably one copy of the _ExceptObjectStack threadvar. Will this still be true if a main program and a dynamic library both include sysinit.o ?

The sysinit unit contains the entrypoint and directly references symbols provided by the main program, not the RTL, to pass them into the RTL. It simply can't be inside a library. The exception handling is inside the System and SysUtils units, so no conflict there.

Regards,
Sven

Reply by email

Adriaan van Os
to Sven Barth
Sven Barth wrote 14 lines
Adriaan van Os via fpc-devel < > schrieb am Di., 29. Okt. 2024, 15:47: The idea of building the RTL in a dynamic ibrary is to have one copy of the RTL threadvars, notably one copy of the _ExceptObjectStack threadvar. Will this still be true if a main program and a dynamic library both include sysinit.o ? The sysinit unit contains the entrypoint and directly references symbols provided by the main program, not the RTL, to pass them into the RTL. It simply can't be inside a library. The exception handling is inside the System and SysUtils units, so no conflict there.

sysinit.o contains _FPC_LIBMAIN and thus has to be linked in when creating a dynamic library compiled with FPC. The crucial question is — do we then end up with one or two copies of the _ExceptObjectStack threadvar ?

Regards,

Adriaan van Os

Reply by email

Sven Barth
to Adriaan van Os

Adriaan van Os via fpc-devel schrieb am
Mi., 30. Okt. 2024, 06:50:

Show quoted text 22 lines
Sven Barth via fpc-devel wrote: > Adriaan van Os via fpc-devel < > > schrieb am Di., 29. Okt. 2024, > 15:47: > The idea of building the RTL in a dynamic ibrary is to have one copy > of the RTL threadvars, notably > one copy of the _ExceptObjectStack threadvar. Will this still be > true if a main program and a > dynamic library both include sysinit.o ? > > > The sysinit unit contains the entrypoint and directly references symbols > provided by the main program, not the RTL, to pass them into the RTL. It > simply can't be inside a library. The exception handling is inside the > System and SysUtils units, so no conflict there. sysinit.o contains _FPC_LIBMAIN and thus has to be linked in when creating a dynamic library compiled with FPC. The crucial question is — do we then end up with one or two copies of the _ExceptObjectStack threadvar ?

_FPC_LIBMAIN is for files with the header "library". Units moved to a shared library don't have a need for that symbol, because they'll be called from the main program.
And if you should have a FPC library then you need to make sure that it's linked against the same shared RTL library to avoid issues. Only if a library links in its own RTL there will be separate symbols instead of shared ones.

Regards,
Sven

Reply by email