[SOLVED] QT5 with latest Lazarus has undefined references

[zeljko]

It is safe to push libQt5Pas 1.2.9 to distro maintainers, if someone know such ppl then pls ask them to update libQt5Pas

[MarkMLl]

As I mentioned above, qmake and libqt5x11extras-dev. Probably will have everything else.

Sorry, I'd missed that bit.

libqt5x11extras5-dev (note extra digit) on Debian which also pulls in libglu1-mesa-dev libqt5opengl5-dev libvulkan-dev qt5-qmake qt5-qmake-bin qtbase5-dev qtbase5-dev-tools.

qmake -query now runs OK which I presume is an indication prerequisites are OK. qmake qt=qt5 runs to successful completion. make runs to successful completion. I've not tried going further pending working out where it's being installed and what the implications are.

Debian Testing is in a feature freeze mode now, wonder if we should be pushing to get this "new and improved" lib into it ?  Will have to test to see it does not break Lazarus 2.0.12 for example. Sigh ...

The kernel version is still drifting upwards, and I think it would be worth pointing out the desirability of getting this prerequisite library up to something which is possibly slightly in advance of the Lazarus version frozen for the distro.

MarkMLl

[ChrisR]

I also note that the Ubuntu packages
  https://packages.ubuntu.com/focal/libdevel/libqt5pas-dev
link to code from 2013
  http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html
I actually like how David Bannon separates this library from the rest of Lazarus.
  https://github.com/davidbannon/libqt5pas
However, he is not the developer, so he does not know when a new version is required. Since zeljko is spear-heading the impressive development of the QT5 widgetset, perhaps he should choose the best way to maintain and describe this library. One option is that the Lazarus community deems David Banoons repository the official one, with zeljko telling him when a new release should be created. We could then update all the Lazarus wikis to point to a single unified solution for this. As GTK2 is getting old, and GTK3 has many regressions (at least from my perspective as an OpenGL developer), the mature QT5 seems the future of Lazarus. I think the community would benefit from a unified mechanism for promoting this required library.

[MarkMLl]

If anybody does fix this (or becomes aware of its having been fixed) in a way that doesn't need a locally-generated binding library please could they append something to this thread so that we all know.

Temporarily fixed by reverting to revision 64919.

MarkMLl

[dbannon]

OK, I have run a number of tests that indicate the new libraries are backwards compatible so older versions of Lazarus seem quite happy to use the new libraries. (The reverse is not the case however!).

So, I have logged a debian bug against bullseye in the hope they they will accept the new model into bullseye before it becomes 'stable'. That will set a transition happening at least.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986495

In the mean time (ie several years) I suggest we (Qt5 and trunk users) need to manually install the new library on our own systems but make sure we compile release packages with, eg, Lazarus 2.0.12 ensuring compatibility with the libqt5pas libraries that will be out in user land for some time.

The alternative is, of course, we have to tell end users they need to manually install the new libraries, perhaps from  https://github.com/davidbannon/libqt5pas. Users hate that !  Ubuntu and friends users could use a PPA but thats only slightly less popular and does not help all the other distro users.

Davo

[dbannon]

If anybody does fix this (or becomes aware of its having been fixed) in a way that doesn't need a locally-generated binding library please could they append something to this thread so that we all know.

https://github.com/davidbannon/libqt5pas/releases/tag/v1.2.9 - downloading and installing either deb or rpm is certainly easier than "locally-generating" but not a solution IMHO.

In addition, I am happy to add just a tar of the necessary files, would consist of just a library and a couple of symlinks that need be copied into (usually) /usr/lib/x86_64-linux-gnu. Thats won't, of course satisfy a package that has been declared to depend on libqt5pas.  Perhaps we need a 32bit version as well.

And creating a PPA would help too, Ubuntu users, and users of distros based on Ubuntu would at least get auto updates. But its still a very blunt weapon. Upgrades to your OS usually cancel all PPAs and again, end users always feel very uncomfortable about configuring PPAs. And PPAs have to be based on source packages ...

Personally, I think the accessibility changes made to Lazarus's Qt5 might be better done with an opt in #DEFINE approach.

Davo

[MarkMLl]

Personally, I think the accessibility changes made to Lazarus's Qt5 might be better done with an opt in #DEFINE approach.

Or by loading the relevant procedures dynamically (i.e. on-demand rather than at the start of execution).

A few years ago I think I raised a bug asking for a compiler facility to check for the existence of a library, something like that might possibly help but obviously wouldn't fix the situation where a binary if moved from an up-to-date development system to a slightly older production system (with no development tools for security purposes).

Could possibly do with a note in the cbindings readme saying what the prerequisite packages are for various distreaux.

MarkMLl

[dbannon]

I have had a response from the Debian people, no, they are not interested in updating the version of libqt5pas as their policy is quite clear, the existing library works fine with the RELEASE version of Lazarus they currently support (and that is not going to change between now and release of Bullseye).  And honestly, I consider that quite a reasonable position.

I don't believe what we have now is workable. Every new user who tries out Lazarus Trunk and Qt5 is going to get an incomprehensible error message and will walk away shaking his or her head sadly.  If the changes propagate into the next Lazarus release, its even worse.

With (eg) Debian having a two year release cycle, any application we build with either trunk or a newly released Lazarus will fail unless the end user manually updates their own libqt5pas library. And thats a massive turn off for end users.

I propose that we make the recent changes to the Lazarus code (NOT the C library code) subject to a #ifdef. zeljko has done much of that much of that already, all the Lazarus cbindings have moved out of qt5.pas and into qt56.pas.   qt5.pas just has an include, we make that include subject to the #ifdef

So, we reintroduce the 'old' qt5.pas as qt56stable.pas back into the repo and change q5.pas to -

Code: Pascal  [Select][+][-]

1. {$I qtdefines.inc}
2.  
3. { Enabling the next define will allow use of the accessibility functions now built into Lazarus QT5.
4.   But that requires manually installed new versions of the libqt5pas library.  See the cbinding
5.   directory for build instructions or see https://github.com/davidbannon/libqt5pas   }
6. // {$define QT5DEV}  
7. {$ifdef QT5DEV}
8. {$i qt56.pas}
9. {$else}
10. {$i qt56stable.pas}
11. {$endif}        

The library (and dev library) remain the same, as distros pick them up, they will get the new code, eventually all distros will have the new code and the above setting can become the default. In the mean time, developers and end users who need the new facilities can install them, other people will be able to continue working in the mean time.

This new approach needs to be documented on the wiki. I also believe the new accessibility features need to be documented too. All we have at the moment is a bug report.

I have not tested the above proposal and if there are more changes than I expect to the common C code it will be more complicated than I present but its a start !

Is this an acceptable approach ?

Davo

[MarkMLl]

@dbannon it looks a reasonable approach, but it definitely needs comments (i.e. like you've done) in appropriate places so that any distro maintainer casually packing it knows what's going on: it's not reasonable to expect them to go hunting in the wiki.

And there's still the risk that because the existing library works they won't pick up the new one.

MarkMLl

[dbannon]

No, I am afraid my guesses about the extent of the changes made a few days ago was wildly optimistic.  Here is a summary of what changed in the pascal code (ie excluding the C code used to build the library, no need to 'manage' that) -

interfaces/qt5/qt56.pas differ     295 additional lines
interfaces/qt5/qtobject.inc differ    1 line
interfaces/qt5/qtwidgets.pas differ   462 additional lines
interfaces/qt5/qtwscomctrls.pp differ  1 line
interfaces/qt5/qtwscontrols.pp differ  48 additional lines
interfaces/qt5/qtwsfactory.pas differ  3 lines

While it could be possible to manage those changes with some compile directives, its not going to be be pretty. It will be a fair bit of work and will leave the code a bit harder to maintain. And I wonder if such a patch would be acceptable ?

Trouble is, I cannot see any other approach that even vaguely addresses this problem.  Can anyone else ?

Davo

[MarkMLl]

I've not got the relevant code in front of me at the moment, but is it safe to conclude that a substantial number of those changes are declarative so don't depend on the binary (shared object) of the updated binding?

Could the changes be reduced to a small number of function calls which could be handled using run-time dynamic linkage?

MarkMLl

[dbannon]

I've not got the relevant code in front of me at the moment, but is it safe to conclude that a substantial number of those changes are declarative so don't depend on the binary (shared object) of the updated binding?

You mean as long as they are not called, it does not matter that they point nowhere ?  A good number but not more that 20% as a guess.

Could the changes be reduced to a small number of function calls which could be handled using run-time dynamic linkage?

No, not without restructuring Z's code, not something I am not willing to risk !

On the other hand, quite a lot will be in a small number of blocks requiring minimal intervention.

But the real question is, are the Powers that Be willing to accept such an ugly hack ?  It would probably have to be in there for at least two to three years ?

Davo

[MarkMLl]

But the real question is, are the Powers that Be willing to accept such an ugly hack ?  It would probably have to be in there for at least two to three years ?

There's a number of possibilities:

* Dump all the Qt5 stuff and revert to an older version... which is now unsupported by most distreaux.

* Force all users to upgrade their binding library, which would be extremely bad PR from FPC's POV.

* Fork "bigide" to have "accessible_bigide" or similar, or the platform name to include Accessible_Qt5.

* Modify the problematic patch so that if it tried to call the unimplemented function it would fail or raise an exception, which would need run-time dynamic linkage.

* Dump the patch that caused the problem as unachievable until the distreaux have caught up.

If anybody can see any others then for $DEITY's sake add them, but I think that only the final three are viable.

MarkMLl

[dbannon]

Well, turns out its not as ugly as I feared. I have added only 19 $ifdef and it compiles nicely !

Controlling with a $DEFINE in qtdefines.inc - thats going to need some more thought.

Think I'll head of to bed now, maybe we'll get some feed back from the developers ....

Davo

[MarkMLl]

qt56.pas is a bit of a beast. I have a tool which would semi-automatically convert that into an object containing lots of procedure/function pointers which would be nil where the target was unavailable in the .so, but I'm reluctant to try that by myself since (a) it doesn't handle the explicit specification of the entry-point name, (b) it's untested with any OS other than Linux x86_64 and I'm not in a position to support other platforms, and (c) all the points where it was being referenced would have to be qualified with an explicit qt56 to get everything to work properly.

The first of those could of course turn out to be a "non problem" if the external and internal names never differed, but verifying that and accommodating the redundant name specification would be a fairly big job in itself (I'm looking at the utility now to see what can be easily improved). Splitting the new stuff into qt56b.pas would probably make every approach easier.

MarkMLl