I am investigating programming for the Raspberry Pi as described in my other thread. Could someone please outline if there is a concept like a Windows DLL also in Raspbian for the Pi?

I have a DLL written in Delphi7 (or 2007), which implements a whole bunch of basic functions and I am wondering if a similar file as a DLL is used in Linux. If so could I port the existing DLL from Windows to freepascal and then to Linux on the Pi?

I got some advice on the porting process in my other thread but in this case it involves the creation of a DLL equivalent so that the main programming could be done in for example Python while using the functions from the DLL code?

As the RPi uses a Linux (at least in normal cases) it also supports shared libraries. They are written in FPC the same way as they are in Delphi (by having a "library xyz" main file with an "exports" clause). This will result in a ".so" file that you can load in FPC using the DynLibs unit with LoadModule() and GetProcAddress() and in C-based languages using dlopen()/dlsym() (don't know what Python uses, but I bet it's the same across platforms ;) ).
Things to keep in mind though:
- declare exported functions as "cdecl"
- WideString is - unlike on Windows - not cross-library-safe
- and of course the usual points regarding strings, objects, etc. apply

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150920/830aed75/attachment-0001.html>

Could someone please outline if there is a concept like a Windows DLL also

in Raspbian for the Pi?

Get yourself a bunch of basic Linux (or *nix in general) concept and implementation first. Don't jump in to the world you don't know about.

If so could I port the existing DLL from Windows to freepascal and then to Linux on the Pi?

Depends on a lot of factor.
http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide applies.

I got some advice on the porting process in my other thread but in

this case it involves the creation of a DLL equivalent so that the main programming could be done in for example Python while using the functions from the DLL code?

As long as you know how Python convention for dynamic libraries, this can of course be done.

It's a .so file. I think Lazarus has the same restrictions for both Windows and unix: by default, there's a separate heap in the main executable and in each separately-linked .so library which means that you can't pass anything dynamically-allocated (strings, objects etc.) as parameters or (in particular) return them as results. The way round this is to use this at the start of each .lpr:

uses
cmem, { HeapTrc, } Classes, interfaces
{ you can add units after this }

Then in the library .lpr you have an exports list for entry points.

Bo Berglund wrote

I have a DLL written in Delphi7 (or 2007), which implements a whole bunch of basic functions ...

While if course in Linux a "dynamic link" concept like DLL does exist and is widely used ("Shared Objects" ".so - files") why would you want to use it in this project ?

DLLs/sos make sense if used by multiple executable. If you only do a single executable it will be easier do use a decent unit concept in Delphi or Lazarus.

Moreover Delphi supports "Runtime Libraries" to create a special kind of DLLs, that are only usable by Delphi applications. Lazarus does not (yet) support this concept and hence doing DLLs /sos needs to be done on a rather "basic" level.

-Michael

A shot in the dark maybe...
But a couple of years back I ported the existing server code into a DLL where the main functionality was accessible in order for a university customer to be able to use it for their research project using their own code. The DLL is usable both from Delphi and Visual Basic so they can throw together their own processing and use the DLL to access the instrument easily.

So I thought that maybe I could do the same here and have something that a main program created natively in Python for instance could use.

But I agree it would be better to create a full FPC program instead using the proper selection of units from the DLL project for instance.

Bo Berglund wrote

So I thought that maybe I could do the same here and have something that a main program created natively in Python for instance could use.

Of course you _can_ do DLLs / sos for inter-language linking. But then they need a "standard" "flat" interface (no strings, no objects, ...) and this would make the project a lot more complicated than just using Delphi units.

-Michael