[Lazarus] FYI: Shared Libraries support

[Thierry Coq]

Hello,

I don't understand the issue. As Razvan writes, isn't it an OS issue? 
For example, please find attached a small but complete example I've 
scratched together this morning to show how one can use <dynamically> 
DLLs in Windows. Obviously, a minor variation of the code could easily 
be done for the various linuxes.

FPC and Lazarus therefore do have <today> the capacity for dynamic 
loading of DLLs. It may be the compiler could add some syntactic glue, 
but nothing a competent programmer cannot do on his own with minor work, 
or encapsulate within a component. See the example. I guess GLScene is 
doing it already.

Or is there something I have missed here?
Best regards,
Thierry Coq

Razvan Adrian Bogdan a écrit :
> On Linux they used the OS abilities and naming rules to prevent a dll
> hell, since a typical Linux system contains at least twice (usually
> much more) the number of libraries and applications than your windows
> machine, if you have a 64 bit Linux you will see how nice libs are
> placed and with simple symlinks and version in .so names, there are
> absolutely no naming conflicts, still with all binaries in one place
> it manages to avoid the dll hell and make everyone happy.
> I assume OSX also played it smart but OSX had more planning in the first place.
> The only platform with dll hell is windows, because it didn't support
> any type of links until NTFS hard links that few know about or use, on
> windows Borland was smart enough to include versions in their .bpl
> files for each Delphi version, maybe M$ should have folowed the
> example  instead of inventing a squared iron wheel covered in rubber
> named an "assembly" that tricks your app into dynamically loading
> whatever dll the user wants you to load, can't we implement such
> mechanism ourselvs.
> I like the way Zeos Components make use of such dynamic loading and
> use different dlls and could even have multiple versions of the same
> dll loaded at once and change between those at runtime, it is a simple
> as creating a record structure holding the dlls functions and making
> instances of this record and dynamically loading every version of the
> dll, it is even more advanced than the assembly concept because you
> can chose from the application what dll to load and even use more than
> one version of it. I think FPC could make dynamic dll loading using
> the current static dll loading syntax or very similar syntax if you
> are too lazy to write a dynamic loader but then again how much use
> would it have to have almost the same syntax, maybe it would help
> automatic converters.
>
> Razvan
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
>