Delayed Widgetset Binding

[msintle]

Is it possible to dynamically bind to widgetsets in various Linux and CPU architectures?

For instance, on an OS where the targeted widgetset is missing (say GTK2 or Qt5), having this as the first line of the app:

WritenLn('Hello World');

Is never shown - instead, a shared library load error pertaining to the missing widgetset is displayed (proving that dynamic binding is not available by default).

[TRon]

Is it possible to dynamically bind to widgetsets in various Linux and CPU architectures?

Yeah, sure that is not a problem. Just requires some rewriting. see also https://www.freepascal.org/docs-html/rtl/dynlibs/index.html

Is never shown - instead, a shared library load error pertaining to the missing widgetset is displayed (proving that dynamic binding is not available by default).

But using dynamic loading will not solve that issue. What is your order of units ? In what order are the libraries automatically loaded for you (hint: in their initialization section) ?

[msintle]

For example look at something like this:

uses
  Dynlibs,
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes, SysUtils, CustApp
  { you can add units after this }
  , Interfaces, LCLType, INIFiles,
  {$IFDEF DARWIN}MacOSAll,{$ELSE}Process,{$ENDIF}{$IFNDEF WINDOWS}BaseUnix,
  Unix, Dos{$ELSE}ShellAPI{$ENDIF}
  ;

The moment these are added in, automatically, the compiled New | Project | Console Application breaks, in ways like these:

error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory

On a particular Linux, other Linux'es have other errors, etc.

This is before any functions are even consumed yet from the main code body, so it seems to me dynamic loading of the widgetsets is not implemented by default.

If it is, how do I enable it?

[Martin_fr]

Widgetset and cpu are 2 different things.

CPU
I don't know if (and if yes then for which of the OS) you can write a single executable that can executed on diff CPU (e.g. intel or arm). And I mean without the host system emulating a cpu.

Widgetset

If you mean a single app (using LCL) that runs on gtk and QT => No, I am pretty sure that is not currently supported.


As for writeln => that depends if a console (or other output) is assigned to stdout. (On Window, you can use the Windows kernel API to open a console, but you need to google).

However if the LCL for a Widgetset (such as gtk) has hard-linked library dependencies, then you can't just check.
You could have a loader app, that then loads the real app, if it knows it will work.

[msintle]

Hi again, Martin!

By CPU I meant to refer to the variety of operating platforms (ex: x86_64 and AARCH64 Linux flavors), and not building "fat binaries" that can run on both Linux flavors through a single binary.

Regarding widgetset, my goal is not to build a single binary that runs on both Qt5 and GTK2, but rather, a single binary which can run both with and without a targeted widgetset. For example, let's say my binary targets GTK2. If it detects that GTK2 is absent, I would rather have it fall back to console input/output via specific code for that scenario.

However based on my research as shared above (just adding LCL units/package dependencies), this doesn't seem to be possible indeed. The GTK2 and/or Qt5 API calls are statically linked even if they are not being used (or perhaps, unit initializations are still consuming some API calls which is the problem)?

[Martin_fr]

I would have to double check myself, but I believe they are statically (i.e. not using "OpenLibrary") linked (at least some of the calls).

[zeljko]

Martin is correct. Even if you plan to do that you must write complete gtk2/qt dynamically loaded libs, and then if you do that, I'm pretty sure that such app will be much slower than current one. Tehnically it is possible to do that, but it does not worth time IMO.

[Martin_fr]

I don't think it would have noticeable speed impact. You initialize a jump table having all the library functions, once at startup. That may make startup a few millisecs slower, but that's it.
At runtime you have the call via the jumptable. But compared to the actual work inside the call, that wont be noticeable.

But rewriting everything will be a huge task.

[TRon]

But rewriting everything will be a huge task.

I did wrote:

...
Just requires some rewriting.
...

 

[msintle]

Martin is correct. Even if you plan to do that you must write complete gtk2/qt dynamically loaded libs, and then if you do that, I'm pretty sure that such app will be much slower than current one. Tehnically it is possible to do that, but it does not worth time IMO.

I really doubt you'd notice the performance impact of delayed loading, but yeah, I can see for most people there wouldn't be much use to this.

Although with obscure Qt5 libraries for example - like the printing stack and such - it might really help improve compatibility with many Linux'es to do this at least partially at runtime.

[msintle]

I did wrote:

...
Just requires some rewriting.
...

 

Haha.

[PascalDragon]

Martin is correct. Even if you plan to do that you must write complete gtk2/qt dynamically loaded libs, and then if you do that, I'm pretty sure that such app will be much slower than current one. Tehnically it is possible to do that, but it does not worth time IMO.

I really doubt you'd notice the performance impact of delayed loading, but yeah, I can see for most people there wouldn't be much use to this.

It's not only the loading, but also at runtime, because the LCL would have to deal with differences between Qt and GTK at runtime rather than at compiletime as it is right now.