Hi,

Is it possible, or is there something special that needs to be done to create a library that could be used by other languages?

For example. I'm interested in created a library (.dll and .so) of fpGUI Toolkit, so the library can be reused by other fpGUI based applications (reducing deployment size of executables), and allow languages like C to use the fpGUI Library (.DLL and .SO) to create C gui applications. This also means I can deploy "minor fixes" in the fpGUI library, without having te recompile all the applications.

Is this possible with Free Pascal?

Regards,
- Graeme -

1. Not without package support.

2. Since FPGui is object oriented, it will be unusable unless you devise a 'flat' API.

Michael.

Graeme Geldenhuys wrote

Is it possible, or is there something special that needs to be done to create a library that could be used by other languages?

Just make sure that the exported routines
a) are declared as cdecl or stdcall (depending on platform requirements) b) don't have parameters or function results that are Pascal-specific (since you may not be able to represent them in other languages), and in particular no reference-counted, types (local variables don't matter)

Jonas

Michael Van Canneyt wrote

1. Not without package support.

What exactly does that mean? In Lazarus I can go "File > New... > Library" which is a package that compiles to a .so file under Linux.

2. Since FPGui is object oriented, it will be unusable unless you devise a 'flat' API.

Ah, so this is a similar issue to Free Pascal using C++ libraries like Qt? Where the Qt header translation had to flatten all Objects and methods.

Um, you really would have thought Object Oriented Programming would be more usable (reusable code) than that. :-)

Regards,
- Graeme -

Ah yes, I missed the "library can be reused by other fpGUI based applications (reducing deployment size of executables)" part. That indeed requires packages support. Using it from another language doesn't though (but indeed requires flattening the interface).

Jonas

Michael Van Canneyt wrote

2. Since FPGui is object oriented, it will be unusable unless you devise a 'flat' API.

Is't there a way the FPC compiler can automatically flatten object oriented code?

As a test I created a new library project and included the fpgui_toolkit.pas unit which contains references to all units available in fpGUI Toolkit. I had to add the -fPIC compiler parameter and in successfully compiled a fpgui_toolkit.so file.

I know I can't use that file, because no functions have been exported. But viewing the .so file with Midnight Commander (pressing F3) shows me what looks like a 100% flattened API of fpGUI Toolkit - it's probably debug information. But doesn't that mean the compiler could also do something similar an instead generate exported methods (flattened API).

See the URL for a image of what Midnight Commander shows me:

http://opensoft.homeip.net/~graemeg/fpgui_toolkit_lib.so.png

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

No.

As a test I created a new library project and included the fpgui_toolkit.pas unit which contains references to all units available in fpGUI Toolkit. I had to add the -fPIC compiler parameter and in successfully compiled a fpgui_toolkit.so file.

You got a .so file. How do you know it is correct?

You see mangled names, exactly what you would see if you did this on a C++ .so. IOW this dll is not flattened.

Do this on a C dll to see the difference.

Roughly there are only three options:
- wait for packages support
- implement packages support
- export a C api (more or less as Jonas said), and take the more difficult usage (and need to rewrap if you want OO interface) for granted.

Reread the wiki entry to get an idea what packages are about.

I could not say it more concise as this, Marco wrapped it up nicely.

Michael.

Out of curiosity I tried, but I can't find any 'unstripped' .so files on my Linux system. So Midnight Commander doesn't show me anything, other than what architecture the .so file is.

Roughly there are only three options:

OK, to not add any more items to my todo list, I'll forget about the library idea for now. It was worth asking though.

Thanks to all for giving such quick replies.

Reread the wiki entry to get an idea what packages are about.

I just found 3 wiki pages, thanks to Mattias in a similar thread in the Lazarus mailing list. I'm reading through them now.

Regards,
- Graeme -

A dynamic library cannot be completely stripped, because dynamic linking happens using symbol names. If it were completely stripped, it could not be used by any program (except if all the library did was executing initialisation and/or finalisation code, which is highly unlikely).

Jonas

Michael Van Canneyt wrote

I could not say it more concise as this, Marco wrapped it up nicely.

Like I said in a earlier reply, I don't want to add any more work to my already long todo list.

I just thought if it was something quick and easy to do, then it would be nice to allow languages like C to also use fpGUI Toolkit.

But clearly this language relationship is a very one-sided thing. We use their (C/C++) libraries, they don't use ours. :-(

Regards,
- Graeme -

Well, we can use C++ also only when creating a flattened version.

So if you'd create a flattened version of fpGUI, a C or C++ programmer could - in theory - use it.

Michael.

Graeme Geldenhuys wrote

But clearly this language relationship is a very one-sided thing. We use their (C/C++) libraries, they don't use ours. :-(

Just look at the QT bindings. The LCL can't simply use QT, it has to use a wrapper library that flattens the object oriented structure of QT. You have similar problems with most languages. Writing bindings to foreign language libraries is always problematic. C (i.e. a flat API) is usually the common denominator.

Best Regards,
Andreas.