If you hate Unix like systems and don't want to learn their arcane rules, don't use it.
not exactly a helpful comment, Marco.
the symlink created by:
sudo ln -s /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libdl.so
... is ONLY needed on the system you are running FPC on, NOT on any system you are going to run your binary on. hence, either (a) FPC itself should create the symlink, or (b) our patch program should create the symlink, or (c) the FPC source should be modified to not need the symlink.
basically, your application source needs (if FPC worked correctly) to contain somewhere/anywhere the line:
procedure anything; cdecl external 'libdl.so.2';
... where the procedure name doesn't matter. the important part is the
external 'libdl.so.2'. this causes the library file
libdl.so.2 to be added as a "NEEDED" library to the generated ELF binary's header. the procedure name doesn't matter as long as it exists in
libdl or
libc.
but unfortunately FPC, when it sees 'libdl.so.2', covertly converts it to 'libdl.so'. hence we need to manually add the symlink ourself on our development system.
note that this whole argument around the symlink is a Red Herring. the FPC developers will
never allow numeric extensions to library names, while adding the symlink on your development system is trivial. the symlink would probably even work well enough if just added into your project directory - no need for
sudo if done that way, but then needed for each and every project directory.
cheers,
rob :-)
Recent
