Hi Jerry,
Fully agree with you on the need to support exploratory projects in the most helpful way possible. That is present for simple configurations, but cross-compilation appears to be their threshold for support.
The change root should work fine. It’s not as important for C/C++ (non Qt) development now thanks to the new Debian cross build support. Unfortunately, change roots are slow (and a little buggy) when using QEMU.
I haven’t used VisualGDB. I’ll add it to my list of things to try!
Derek.

Hello Derek:
Thanks for the link with instructions for installing QT. It looks like it would be very helpful (but require lots of time and luck). However, I took your comment regarding QT Group’s focus on the commercial aspects of their business to heart. When downloading QT, you are cautioned to carefully review the licensing requirements. This caution might be interpreted as either sound advice to obey the law, or as a veiled warning that you are about to enter a legal minefield.

My concern about the legal dimension is sharpened by Oracle’s 2018 court victory over Google, establishing Oracle’s copyright over the Java API and signaling Oracle’s intent to extract fees for its use. It seems like this ruling (if upheld on appeal) could have implications for QT. The folks at QT certainly need and deserve to get paid for their work, but many small exploratory projects can’t shoulder the monthly licensing fees (for the life of the product?) for the QT commercial version. Some sort of GUI seems to be needed on many projects, so some means of developing Beagebone projects with a GUI is crucial. So, I’ve been laboring to understand how use GTK instead.

Since developing on the Beagleboard itself is painfully slow and can run into memory limits (at least with QT) I need to crossbuild on my PC. However, my mind boggles at the complications of properly installing the arm GTK libraries and setting Eclipse to properly handle them. After several failed attempts to get this to work in Eclipse in the basic VirtualBox VM, I figured it might be better to use the Change Root approach described in the first edition of your book, making the PC appear to be an arm processor. However, I see that this section on Change Root does not appear in the 2nd edition. Are there problems with Change Root in Debian 9?

Possibly, I needn’t worry about licensing issues for the open source version QT. If this is the case, I noticed that the product VisualGDB claims to provide crossbuilding QT for the BeagleBone in a Windows environment at very reasonable cost. Are you aware of users that had success with this tool without lots of painful setup using the Debian Stretch build for the BeagleBone?

Thanks,
Jerry

Hi Lewis,
See the message above to Jerry Smith. No, I’m afraid that Qt development on the Beagle boards was the only way that I could support Qt for this edition.
Kind regards,
Derek.

Hi Jerry,
Thanks for your feedback. Yes, I had to drop cross-building Qt from the Raspberry Pi and Second Revision of Exploring Beaglebone. The problem is that cross building Qt is overly onerous and the process changes too quickly to be captured by a text book. When I wrote the instructions for Qt in Revision 1 there was much more support for open source development with Qt. Today, Qt Group PLC are focused on their commercial offerings and professional services, and the support for open source development has wained.

The best description I am aware of is at: https://medium.com/@amirmann/how-to-cross-compile-qt-for-raspberry-pi-3-on-linux-ubuntu-for-beginners-75acf2a078c and the number of steps is daunting!

Unfortunately, the only way I could bring Qt into the book was to build the programs on the Beagle board itself.

Kind regards,
Derek.

Hello thank you for answer,
I was strugling with the problem for so long without solution (tried everything I think, checked persmissions etc) that I decided to watch the keyboard input manually, similar to the way you introduced with GPIO-KEYS. I am not proud of it, but at least it finally works.

Hi Łukasz, I haven’t seen that before — very odd. Check the permissions on /dev/input/event1. You could also try strace on the program (when you don’t run it as root) to monitor the interactions between in an the kernel. I’m afraid that I’m at a loss as to what is wrong. Sorry, Derek.

Thanks Steve and Iman — great info for those that are trying the same thing. I’ll have to work through it again when I get some time, Derek.

Hi Steve

Tha’s a good news.
I hope I get a chance in this weekend to run a full step and when I find it work share it.

Thank you
Iman