[fpc-devel]Dynamic libs and ansistring constants

Michael.VanCanneyt at Wisa.be Michael.VanCanneyt at Wisa.be
Wed Sep 18 19:15:14 CEST 2002

On Wed, 18 Sep 2002, Mattias Gaertner wrote:

> Hi all,
> I'm not sure if this topic belongs to this list, but I need the help of some fpc cracks.
> Andrew and I are trying to implement a basic package system for lazarus.
> Therefore we use dynamic libs that can be loaded and unloaded at runtime (see dynlibs.pp).
> The first problem we met was, that everything that is shared between the IDE and the package must be in dynamically libs. If someone knows how to do it with statically things, plz tell me.
> Because fpc provides only statically files on default, we converted all ppu files of the fpc packages into libs via the ppumove program. This was quite simple. A nice side effect is, that programs are much smaller.
> The second problem is that typed const do not work. For example a 'const p: pointer=nil;' results in variables at the same address. I guess, that is what Florian ment with unsupported PIC. Because typed const can simply be replaced with vars, this is only a small drawback.
> Then we encountered a more serious problem:
> Const ansistrings in loaded code can't be unreferenced if code is unloaded.
> For example:
> - A lib is loaded via LoadLibrary.
> - The lib calls a proc in another lib:
>      DoSomething('Ahoi');
>   The 'Ahoi' is a constant ansistring.
> - The lib is unloaded
> - Now the code is gone and so is the const in the textsegment. But because ansistrings
>   are pointers (with reference counters and length) using them after the unloading
>   results in exception.
> The only solution here is to make sure that all const strings are unused after
> the lib is unloaded. (e.g. UniqueString or special parameter specifier, ... ).
> But this is not a clean solution. Heaptrc shows, that every use of a const string in an unloaded package leaves an unreleased pointer.
> Questions:
> Do we really need to convert all fpc ppu files into libraries or is there a better solution?

There is no better solution at this point.

> Why does a const string in an unloaded lib leaves an unreleased pointer?

On windows: because the memory space of the library and loading program
are different, the memory allocated by the main program cannot be released
by the library and vice versa. I am not sure about libraries on linux, but
I'm fairly convinced that it will be the same.

This is why you need to use borlands sharedmm unit - it implements a
heapmanager that uses shared memory between the library and the calling
program. But as I said, I'm not sure how it works on Linux.


More information about the fpc-devel mailing list