How to dynamically link .so file on linux platforms?

[Superdisk]

On Windows, this program will compile and run:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. procedure DoStuff; cdecl; external 'FakeExample.dll';
4.  
5. begin
6.   DoStuff;
7. end.

However, it will pop up a messagebox saying that FakeExample.dll can't be found.

I'm cross-compiling to Linux, and I try to compile this program:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. procedure DoStuff; cdecl; external 'libFakeExample.so';
4.  
5. begin
6.   DoStuff;
7. end.
8.                    

               

and I get an error:

C:\fpcupdeluxe\cross\bin\x86_64-linux\x86_64-linux-ld.exe: cannot find -lFakeExample
project1.lpr(7,1) Error: Error while linking

I don't want to link the library at link-time, I want to dynamically link it (as I would a DLL). How do I do this?

[dsiders]

On Windows, this program will compile and run:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. procedure DoStuff; cdecl; external 'FakeExample.dll';
4.  
5. begin
6.   DoStuff;
7. end.

However, it will pop up a messagebox saying that FakeExample.dll can't be found.

I'm cross-compiling to Linux, and I try to compile this program:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. procedure DoStuff; cdecl; external 'libFakeExample.so';
4.  
5. begin
6.   DoStuff;
7. end.
8.                    

               

and I get an error:

C:\fpcupdeluxe\cross\bin\x86_64-linux\x86_64-linux-ld.exe: cannot find -lFakeExample
project1.lpr(7,1) Error: Error while linking

I don't want to link the library at link-time, I want to dynamically link it (as I would a DLL). How do I do this?

Check the Free Pascal Programmer’s Guide, Chapter 12 Programming shared libraries, 12.3 Using a library in a pascal program.

https://www.freepascal.org/docs-html/current/prog/progse56.html#x266-28200012.3

[marcov]

Both are static linking of a dynamic library. (real dynamic would be with loadlibrary/dlopen)

It just happens that Linux binary architecture requires .so's presents, and Windows not. Not much that you can do there.

[Superdisk]

Wow, that really sucks. Does that mean the FPC crosscompiler for Linux actually ships with the GTK .so files and stuff?

[Cyrax]

Wow, that really sucks. Does that mean the FPC crosscompiler for Linux actually ships with the GTK .so files and stuff?

Nope. You will have to hunt and download them from Linux distribution repositories.

[marcov]

Wow, that really sucks. Does that mean the FPC crosscompiler for Linux actually ships with the GTK .so files and stuff?

No. That is the other disadvantage. All those libs are distribution and version dependent. 

[guest65109]

Wow, that really sucks. Does that mean the FPC crosscompiler for Linux actually ships with the GTK .so files and stuff?

Nope. You will have to hunt and download them from Linux distribution repositories.

Then VirtualBox straight forward. Setup a Linux distro and compile your code there. I recommend MX Linux.

[MarkMLl]

Then VirtualBox straight forward. Setup a Linux distro and compile your code there. I recommend MX Linux.

For some small value of "straightforward". There is still the problem of poorly documented (and often poorly-understood) situations where there is a dependency not only on the package containing the .so file but also on the corresponding -dev package since it is the latter which sets up some crucial symlink.

I'd also add that I've got a downer on VirtualBox because it has a backdoor from the guest to driver code on the host. That results in a false sense of security when running code which might not be entirely trustworthy.

MarkMLl

[Superdisk]

I've been using the FPCUpDeluxe install of the crosscompiler, which ships with crosslibs for Linux, so I can compile regular GUI programs fine. The problem is that I'm trying to link to SDL2. On Windows it's fine since the DLL doesn't need to be there at linktime, but (as I learned from this thread) on Linux the .so does. How nice.

I installed libsdl2-dev on an Ubuntu VM and copied it over to my Windows machine, but it started referencing other .so files which ended up being sort of a rabbit hole.

I'm going to try compiling SDL2 from source with fewer features enabled (I just need the audio capabilities) and see what I can do.

Initially I tried to just compile on Linux directly, however the program is 32 bit and it's damn near impossible to get FPC to compile a 32 bit binary on Linux.

[DonAlfredo]

As maintainer of fpcupdeluxe, I am working on an program that filters and copies the needed libs by looking at the library requirements themselves (with objdump or ldd or file). If working, this should auto-resolve your rabbit hole by adding libsdl2 into the requirements of the libraries.
Stay tuned.

[guest65109]

As maintainer of fpcupdeluxe, I am working on an program that filters and copies the needed libs by looking at the library requirements themselves (with objdump or ldd or file). If working, this should auto-resolve your rabbit hole by adding libsdl2 into the requirements of the libraries.
Stay tuned.

You have done an awesome job with fpcupdeluxe. Thank you.

[marcov]

As maintainer of fpcupdeluxe, I am working on an program that filters and copies the needed libs by looking at the library requirements themselves (with objdump or ldd or file). If working, this should auto-resolve your rabbit hole by adding libsdl2 into the requirements of the libraries.
Stay tuned.

(cut out the middleman and get that yourself? There are fairly complex ELFreaders and writers for heaptrc and resources. Might be possible to make a Pascal ldd in library form)

[garlar27]

I've been using the FPCUpDeluxe install of the crosscompiler, which ships with crosslibs for Linux, so I can compile regular GUI programs fine. The problem is that I'm trying to link to SDL2. On Windows it's fine since the DLL doesn't need to be there at linktime, but (as I learned from this thread) on Linux the .so does. How nice.

I installed libsdl2-dev on an Ubuntu VM and copied it over to my Windows machine, but it started referencing other .so files which ended up being sort of a rabbit hole.

I'm going to try compiling SDL2 from source with fewer features enabled (I just need the audio capabilities) and see what I can do.

Initially I tried to just compile on Linux directly, however the program is 32 bit and it's damn near impossible to get FPC to compile a 32 bit binary on Linux.

I use Dynamic Library Linking on my projects. The advantage of that is
1- You don't need the library to compile the project
2- You don't need the library to run the binary if you won't use it on a particular configuration.
3- If you don't have the library and you need it then you can show an error message to the user instead of the program not starting when the library is not present on the system.