Shared objects has not a high priority for the current fpc developpers. It's a complex issue that needs a good layout, else you end up with all kind of version problems. And for packages it maybe needs more things to register when loading the package

You can use dynamic libs with fpc (including object pascal). There is a dynlibs.pp in the fpc1.1 cvs, which can also be used with 1.0.7. Creating dynamic libs with object pascal support is very easy with the ppumove program.
But fpc does not yet fully support it and so there are some drawbacks:
- You can't use typed consts. Since the LCL is almost circle free it is no problem to get rid of the typed consts in the LCL. But we have
also to make sure, that no fpc lib is using them.
- You can't unload dyn libs when using ansistring constants. This is no problem
for normal programs. But it is a big problem for the package system.
- Under windows you have to use a special heapmanager from borland.
- You have to convert _all_ used fpc libs (ppu files) into dynamic libs.

Under linux this is pretty easy.

There might be some other drawbacks, but these were enough for me to decide, that the Lazarus package system has to wait for fpc. So, it might be possible to create a dynamic LCL lib under linux.

Mattias

> I disagree with that. If you compile without all the debug code, it's > quite small. My entire CheckBook Tracker application is still less than > 2 MB and it's no small application. It's a heck of a lot smaller than > everything required to run GnuCash with it's library structure.

2M is quite a big executable. The problem that it is impossible to make a small app less than 300 K (including upx-ing). So, we have got that think, which was in Delphi. Huge apps, which doing almost nothing. But they are even huger. Despite machines are more powerfull, we shouldn't use it by such a bad way.
And, if we want making many small utilites, it is reasonable to make a gui as a shared object, as it done for many langs (libstdc++ etc).

Vasily I. Volchenko wrote

As I see, it was a great problem. So, lazarus executables are huge.

I disagree with that. If you compile without all the debug code, it's quite small. My entire CheckBook Tracker application is still less than 2 MB and it's no small application. It's a heck of a lot smaller than everything required to run GnuCash with it's library structure. And look how many people can't even get GnuCash to run. If you want a distributable small executable, uncheck "Display Line Numbers" and check "Strip Symbols from Executable" in the linking options in Lazarus before building.

If you start placing things in shared objects that everyone's different app tries to access suddenly it will look like Linux and you'll have people whining that "My XYZ app requires version 0.9.8 and my ABC app required 1.0.3 and they won't work together..." NOT having required libraries is exactly what drove me to Delphi and Lazarus to begin with.

-Tony

Just FYI...

You can avoid this easily on Linux by using versioning, like in .so files. So you would end up with:

lib/lazvcl.0.9.8.so
lib/lazvcl.1.0.3.so
lib/lazvcl.1 -> lazvcl.1.0.3 (symlink)
lib/lazvcl.0 -> lazvcl.0.9.8 (symlink)
lib/lazvcl.so -> lazvcl.1 (symlink)

and linking either to exact version of library, or version 1, or just any version. On Windows, this should be technically possible, too.

And you can turn off shared libs/packages in Delphi, too (in fact, I never turn it on).

Michal

Vasily I. Volchenko wrote

2M is quite a big executable. The problem that it is impossible to make a small app less than 300 K (including upx-ing). So, we have got that think,

I agree and see your point. However from my personal use perspective, It's not an issue because I would never try to write a tiny console application with Lazarus partly because I have no need, and partly because that's not really what Lazarus is designed for (I state that based on my experience with Delphi - perhaps Mattias has a different opinion of Lazarus)

When you say my 2 MB is huge for an executable, consider that when I installed GnuCash - a package similar to my application - I had to download over 15 megs of multiple files and I had to get the versions that came with my distro because if I tried to download the latest versions too many conflicts arose and packages wouldn't install. It was very frustrating. I'd rather have a simple 2 MB executable than a 15 MB hell. But that's just personal opinion. Like I say, I certainly see where you are coming from.

I feel that most of the new class of average Linux users would agree that they would rather have ease of use and waste a few megs of hard disk space when multiple applications incorporate the same code within themselves. I know when I first got started with Linux if I had much in the way of library version incompatibilities I would instantly give up and find another program to install. I know enough now to know how to track down what I need to install, but I still hate doing it.

--Tony

FYI, there is also an internal .so numbering, use objdump to display it. IIRC this is the value put in the executable when linking the program to a shared library.

As I see, it was a great problem. So, lazarus executables are huge. It would be a good idea to place the code in shared object, one for all executables. But... Classes and shared objects are antagonists. But it is not impossible to place classes.o and others to shared object, and then... Then just
fpc -Fn ____
Fixing link.res.
And linking!
The result is tiny executable. I tried this. There were some good results (not with ld, but with gcc), but much more problems.