problems building qt with tslib

The straightforward method will be to overwrite the default touchscreen libraries with your libts* libraries at /usr/lib on the target. Make sure libts-1.0.so.0 points to your libts library and run the application.

If you want to retain both the tslibs, you should set the environment variable QT_PLUGIN_PATH and LD_LIBRARY_PATH as required.

Regards,

Anand

Thanks Anand,

If I understand you correctly, the only files I need on my target machine are the libts* libraries.

For the benefit of others who might stumble across this thread, I can possibly shed some light on some of my earlier questions.

Question 1: where is Qt getting that path from? (path to the tslib plugins)

The root of my problem was, I think, that I did not understand and was not consistent with -prefix as I have built tslib and qt multiple times over the past few weeks.  I had tslib installed in both /usr/lib and in /usr/local/lib.  Qt's use of tslib relies on environment variables and LD_LIBRARY_PATH, and I think that in addition to having multiple installs, I also had some things pointed to the wrong installation.  Once I cleaned that all up, my custom touchscreen plugin is found and loaded OK, and I can now run ts_calibrate, and in Qt, QWSTslibMouseHandlerPrivate no longer has trouble finding the plugin. 

Question 2: what toolchain to use.

I went back to using Code Sourcery toolchain and got Qt to build.  I am taking the Qt doc to be accurate when it says that the only supported toolchain for building QT Embedded for arm is Code Sourcery.  I believe that the TI SDK linux-devkit toolchain is NOT supported and you can't use it to build Qt.  I think that it's probably OK that my kernel is built with the TI toolchain and Qt is built with Code Sourcery.   Not sure what I built tslib with but I should probably use code sourcery for that also.  However, it's my understanding that the Code Sourcery and TI toolchains are not really very different, I think I read somewhere that the only change in the TI tool chain was some arm-specific optimization.  As long as it works, I guess.

Question 3: can anyone build Qt embedded?

Yes, actually I think I succeeded in building 4.7.4 with the Qt toolchain.   I set -prefix to install to a directory on my host machine, pending figuring out what needs to get installed on the target.  The host directory has

I tried building 4.6.2 and that IIRC failed.

Then I went on to 4.7.4 using Code Sourcery, and that build seemed to hang my Ubuntu VM after a long while.

I increased VM memory to 1G and added options to reduce the Qt build:

-nomake examples -nomake demos  -no-opengl -no-webkit -no-javascript-jit -no-scripttools

It's still huge and took hours but it did complete this time.

In my host directory I have these folders:

bin  imports  include  lib  mkspecs  plugins  translations

I expect that all of these need to be copied to the target, but I will go look and see what is on the target now, clean out and save off that stuff, and then replace it with this.

I'll try to get back with a summary of how that worked.

A little more of my apparently endless adventures with Qt and tslib.

Before I got to trying to install my freshly built Qt, I went back and immediately ran into problems with tslib.

Any time I started a Qt application that used tslib, I got an immediate segmentation fault after tslib loaded the plugin.

Today I figured out that when you pass "-host linux-arm-gnu" that argument is the prefix to your toolchain.

But my toolchain is either arm-none-linux-gnueabi (Code Sourcery) or arm-arago-linux-gnueabi (TI devkit).

So I was probably building some totally incompatible version of tslib, probably for my x86 VM host architecture or something.

I got a fresh copy of tslib-1.0 from the link on the TI tslib wiki page:

http://prdownload.berlios.de/tslib/tslib-1.0.tar.bz2

Instead of trying to add a module I modified input-raw.c to match what the panjit puts out for events.

I fixed my configure options to use the TI devkit toolchain, and carefully removed all traces of tslib from the target to start fresh.

 I rebuilt tsblib, ./configure make and make install.

This got me back to a working tslib, ts_test and ts_calibrate.

The next thing was trying my Qt test apps.

They were unhappy because they wanted tslib-1.0.so.0.  But rebuilding the tslib-1.0 sources, I get libts-0.0.so.0.1.1, and symlinks libts-0.1.so.0 and libts.so.

I think the tslib-1.0 got embedded in my Qt apps because there is a tslib that comes with the SDK that is named to match it's version, unlike what the tslib source builds.

I am using CCSv5 to build my Qt test app, and I think it is configured to point to linux-devkit/usr/lib for the libraries, and there is a TI supplied tslib-1.0.so.0 there.

My temporary workaround is to create a symlink from tslib-1.0.so.0 to tslib-0.0.so.0.1.1 on my target, to use the tslib that I built.

Now I can run my test app.  The pointer movement is hopelessly scrambled but at least the Qt app builds and runs and gets some sort of input from tslib.

I'll probably go back to building Qt apps with qmake and make from the command line, as CCSv5 configuration is impossible to figure out.

Good to know that you got the Qt app working with tslib. Can you please mark the thread verified if the query is closed?

Regards,

Anand