gpsd: fix qt build problem

From: Simon Dawson <spdawson@gmail.com>

When gpsd is configured with Qt bindings enabled, the build falls over
because the Qt headers are not found.

A representative build log can be seen at

  http://autobuild.buildroot.org/results/c76888749337788c9ae9a04499f1fc1e1c5a2e81/build-end.log

This patch sets CFLAGS in the environment, so that the headers are found.

Signed-off-by: Simon Dawson <spdawson@gmail.com>
---
 package/gpsd/gpsd.mk |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Le Tue, 24 Jul 2012 21:29:09 +0100,
spdawson@gmail.com a écrit :

>  GPSD_LDFLAGS = $(TARGET_LDFLAGS)
> +GPSD_CFLAGS = $(TARGET_CFLAGS) -I$(STAGING_DIR)/usr/include -I$(STAGING_DIR)/usr/include/QtCore -I$(STAGING_DIR)/usr/include/QtNetwork

I'm sorry but no, this is not the right way of fixing it. The QtCore
and QtNetwork header paths are already on the build command line. It's
just that they are wrong because they have two times the sysroot
location:

/home/test/outputs/gpsd/host/usr/bin/arm-linux-gnueabi-g++ -o gpsutils-qt.os -c -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Wextra -Wall -Wno-uninitialized -Wno-missing-field-initializers -Wcast-align -Wmissing-declarations -Wpointer-arith -Wreturn-type -O2 -fPIC -DUSE_QT -DQT_SHARED -I/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include -I/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/QtNetwork -I/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/QtCore gpsutils.c
gpsutils.c:26:21: fatal error: QDateTime: No such file or directory
compilation terminated.

See
the /home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/home/test/outputs/gpsd/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/QtCore
path. The problem is in the directory arguments passed to Scons.

Best regards,

Thomas

On 24 July 2012 22:00, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I'm sorry but no, this is not the right way of fixing it. The QtCore
> and QtNetwork header paths are already on the build command line. It's
> just that they are wrong because they have two times the sysroot
> location:

Yes, agreed. Thanks for the feedback. (I see that you have now
submitted patches to fix this properly.)

Simon.

Le Wed, 25 Jul 2012 07:42:58 +0100,
Simon Dawson <spdawson@gmail.com> a écrit :

> On 24 July 2012 22:00, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > I'm sorry but no, this is not the right way of fixing it. The QtCore
> > and QtNetwork header paths are already on the build command line. It's
> > just that they are wrong because they have two times the sysroot
> > location:
> 
> Yes, agreed. Thanks for the feedback. (I see that you have now
> submitted patches to fix this properly.)

Well, in fact the problem was not in the arguments passed to scons, but
in the .pc files installed by Qt. They contained the full sysroot
location, while they are not supposed to, so when our special
pkg-config prefixed the locations coming from Qt .pc files by the
sysroot again, we had a wrong path.

I wish I didn't had to do this horrible SED'ing of Qt .pc files after
their installation, but unfortunately, the Qt build system handling of
paths is non-standard and it's really not trivial to get something that
builds, installs in the right place, and has the right prefix.

Best regards,

Thomas

On 25 July 2012 07:47, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I wish I didn't had to do this horrible SED'ing of Qt .pc files after
> their installation, but unfortunately, the Qt build system handling of
> paths is non-standard and it's really not trivial to get something that
> builds, installs in the right place, and has the right prefix.

Sure. It might not be the prettiest of fixes, but it's still a good
find: no doubt this would have caused a problem sooner or later,
regardless of the gpsd issues.

Simon.