Missing includes in STAGING_INCDIR

Missing includes in STAGING_INCDIR

[Tom Cooksey]

I am writing a recipie for Qt/Embedded 4.4 beta (using qt4 recipies as a base). At the 
moment Qt's configure test fails on dbus. I have added -I${STAGING_INCDIR}/dbus-1.0
to the configure flags so the configure test now picks up dbus/dbus.h correctly.

However, dbus.h itself includes dbus/dbus-arch-deps.h, which is not in 
${STAGING_INCDIR}/dbus-1.0/*, but _is_ in the dbus work dir. This means I have to add 
the dbus work dir to the include list, which feels wrong.

I have had the same problem with gstreamer too. I think something has broken recently, 
as I've tried building the existing qtopia core recipies and had the same failures.

I'm building using the org.openembedded.dev & com.gumstix.collection collections for
Angstrom 2008.1, gumstix-verdex machine. Am I missing something?


Cheers,

Tom

Re: Missing includes in STAGING_INCDIR

[Michael 'Mickey' Lauer]

Hi Tom,

On Tuesday 04 March 2008 12:40:17 Tom Cooksey wrote:
> I am writing a recipie for Qt/Embedded 4.4 beta (using qt4 recipies as a
> base). At the moment Qt's configure test fails on dbus. I have added
> -I${STAGING_INCDIR}/dbus-1.0 to the configure flags so the configure test
> now picks up dbus/dbus.h correctly.
>
> However, dbus.h itself includes dbus/dbus-arch-deps.h, which is not in
> ${STAGING_INCDIR}/dbus-1.0/*, but _is_ in the dbus work dir. This means I
> have to add the dbus work dir to the include list, which feels wrong.

Surely that's wrong. Actually dbus-arch-deps.h is where it belongs to, 
${libdir}/dbus-1.0/include/. On my favourite system this is:

tmp/staging/arm-angstrom-linux-gnueabi/lib/dbus-1.0/include/dbus/dbus-arch-deps.h

> I have had the same problem with gstreamer too. I think something has
> broken recently, as I've tried building the existing qtopia core recipies
> and had the same failures.

Just rely on pkgconfig and it will do the job. The relevant excerpt for dbus 
is:

Name: dbus
Description: Free desktop message bus
Version: 1.1.20
Libs: -L${libdir} -ldbus-1
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include

:M:
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Missing includes in STAGING_INCDIR

[Tom Cooksey]

> > I am writing a recipie for Qt/Embedded 4.4 beta (using qt4 recipies as a
> > base). At the moment Qt's configure test fails on dbus. I have added
> > -I${STAGING_INCDIR}/dbus-1.0 to the configure flags so the configure test
> > now picks up dbus/dbus.h correctly.
> >
> > However, dbus.h itself includes dbus/dbus-arch-deps.h, which is not in
> > ${STAGING_INCDIR}/dbus-1.0/*, but _is_ in the dbus work dir. This means I
> > have to add the dbus work dir to the include list, which feels wrong.
> 
> Surely that's wrong. Actually dbus-arch-deps.h is where it belongs to, 
> ${libdir}/dbus-1.0/include/. On my favourite system this is:
> 
> tmp/staging/arm-angstrom-linux-gnueabi/lib/dbus-1.0/include/dbus/dbus-arch-deps.h

Ok, yes, I have this too. Why the two different include paths? Surely 
${STAGING_INCDIR}/dbus-1.0/ is useless without the other?

> > I have had the same problem with gstreamer too. I think something has
> > broken recently, as I've tried building the existing qtopia core recipies
> > and had the same failures.
> 
> Just rely on pkgconfig and it will do the job. The relevant excerpt for dbus 
> is:

Ah... we disable pkgconfig when cross-compiling. ;-) It usually uses the host's includes
and libraries due to most toolchains shipping with broken .pc files. We thought
the compiler spitting out "Can't find ..." is better than "... binary is incompatable".
It looks like OE runs .pc files through sed, is this to fix the same issue?

I'll add ${libdir}/dbus-1.0/include to the configure line. Is libdir or STAGING_LIBDIR
the best to use? Ideally this would go into the mkspec file for the cross-compiler.
Otherwise, it will be passed to the host compiler too (Not that the host compiler's
used much with qmake & friends built seperatly).

I might look into changing the current "patch the mkspecs/common/*" way of doing 
things to actually installing a proper mkspec for the OE cross compiler. Would you 
have any objection to this?

Also, as cross-compiling is supported on Qt/Embedded, I'm doing things "the qt way"
rather than using the cross-compile patch the other qt4 packages use. Don't want
to patch the source if I don't need to.


Cheers,

Tom

Re: Missing includes in STAGING_INCDIR

[Michael 'Mickey' Lauer]

On Tuesday 04 March 2008 13:20:04 Tom Cooksey wrote:
> > > I am writing a recipie for Qt/Embedded 4.4 beta (using qt4 recipies as
> > > a base). At the moment Qt's configure test fails on dbus. I have added
> > > -I${STAGING_INCDIR}/dbus-1.0 to the configure flags so the configure
> > > test now picks up dbus/dbus.h correctly.
> > >
> > > However, dbus.h itself includes dbus/dbus-arch-deps.h, which is not in
> > > ${STAGING_INCDIR}/dbus-1.0/*, but _is_ in the dbus work dir. This means
> > > I have to add the dbus work dir to the include list, which feels wrong.
> >
> > Surely that's wrong. Actually dbus-arch-deps.h is where it belongs to,
> > ${libdir}/dbus-1.0/include/. On my favourite system this is:
> >
> > tmp/staging/arm-angstrom-linux-gnueabi/lib/dbus-1.0/include/dbus/dbus-arc
> >h-deps.h
>
> Ok, yes, I have this too. Why the two different include paths? Surely
> ${STAGING_INCDIR}/dbus-1.0/ is useless without the other?

Don't ask me, this is what upstream decided to do.

> > > I have had the same problem with gstreamer too. I think something has
> > > broken recently, as I've tried building the existing qtopia core
> > > recipies and had the same failures.
> >
> > Just rely on pkgconfig and it will do the job. The relevant excerpt for
> > dbus is:
>
> Ah... we disable pkgconfig when cross-compiling. ;-) It usually uses the
> host's includes and libraries due to most toolchains shipping with broken
> .pc files. We thought the compiler spitting out "Can't find ..." is better
> than "... binary is incompatable". It looks like OE runs .pc files through
> sed, is this to fix the same issue?

Exactly. We think pkgconfig has a lot of value and rather attempted to fix it 
(by sed'ing the .pc files) than to circumvent it. I advise you to do the 
same.

> I'll add ${libdir}/dbus-1.0/include to the configure line. Is libdir or
> STAGING_LIBDIR the best to use?

This would be ${STAGING_LIBDIR}/dbus-1.0/include.

> Ideally this would go into the mkspec file
> for the cross-compiler. Otherwise, it will be passed to the host compiler
> too (Not that the host compiler's used much with qmake & friends built
> seperatly).
>
> I might look into changing the current "patch the mkspecs/common/*" way of
> doing things to actually installing a proper mkspec for the OE cross
> compiler. Would you have any objection to this?

Not at all -- if it's done in a sane way that doesn't break our existing 
applications using qmake.

> Also, as cross-compiling is supported on Qt/Embedded, I'm doing things "the
> qt way" rather than using the cross-compile patch the other qt4 packages
> use. Don't want to patch the source if I don't need to.

Sounds good. We disabled Qt/E thinking it cross-compiles because the configure 
script was doing more harm than good in that case. If you can fix it, we are 
happy.

:M:

-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Missing includes in STAGING_INCDIR

[Tom Cooksey]

> > > > I have had the same problem with gstreamer too. I think something has
> > > > broken recently, as I've tried building the existing qtopia core
> > > > recipies and had the same failures.
> > >
> > > Just rely on pkgconfig and it will do the job. The relevant excerpt for
> > > dbus is:
> >
> > Ah... we disable pkgconfig when cross-compiling. ;-) It usually uses the
> > host's includes and libraries due to most toolchains shipping with broken
> > .pc files. We thought the compiler spitting out "Can't find ..." is better
> > than "... binary is incompatable". It looks like OE runs .pc files through
> > sed, is this to fix the same issue?
> 
> Exactly. We think pkgconfig has a lot of value and rather attempted to fix it 
> (by sed'ing the .pc files) than to circumvent it. I advise you to do the 
> same.

Yup, we like pkgconfig too, saves us a lot of work. :-) Sadly, we have to support 
qt being built on 3rd party toolchains we have no access to and therefore no
way to modify. pkg-config caused a headache for support so we've dropped it
by default when cross-compiling. Hopefully we'll re-enable it in the future as
the pkg-config devs seem to be working on the problem, providing an env 
variable you can use to set a sysroot prefix (PKG_CONFIG_SYSROOT).

> 
> > I'll add ${libdir}/dbus-1.0/include to the configure line. Is libdir or
> > STAGING_LIBDIR the best to use?
> 
> This would be ${STAGING_LIBDIR}/dbus-1.0/include.
> 
> > Ideally this would go into the mkspec file
> > for the cross-compiler. Otherwise, it will be passed to the host compiler
> > too (Not that the host compiler's used much with qmake & friends built
> > seperatly).
> >
> > I might look into changing the current "patch the mkspecs/common/*" way of
> > doing things to actually installing a proper mkspec for the OE cross
> > compiler. Would you have any objection to this?
> 
> Not at all -- if it's done in a sane way that doesn't break our existing 
> applications using qmake.
Well, I'll try to bodge it into the configure line for now. If that fails, I'll dig deeper. Do
you have any examples of packages which use qmake I can test with? snes9x seems
to inherit from qmake_base?

> 
> > Also, as cross-compiling is supported on Qt/Embedded, I'm doing things "the
> > qt way" rather than using the cross-compile patch the other qt4 packages
> > use. Don't want to patch the source if I don't need to.
> 
> Sounds good. We disabled Qt/E thinking it cross-compiles because the configure 
> script was doing more harm than good in that case. If you can fix it, we are 
> happy.
Will do my best. :-)


Cheers,

Tom

Re: Missing includes in STAGING_INCDIR

[Richard Purdie]

On Tue, 2008-03-04 at 13:56 +0100, Tom Cooksey wrote:
> Yup, we like pkgconfig too, saves us a lot of work. :-) Sadly, we have to support 
> qt being built on 3rd party toolchains we have no access to and therefore no
> way to modify. pkg-config caused a headache for support so we've dropped it
> by default when cross-compiling. Hopefully we'll re-enable it in the future as
> the pkg-config devs seem to be working on the problem, providing an env 
> variable you can use to set a sysroot prefix (PKG_CONFIG_SYSROOT).

Just for reference, it was OE users (well, Poky) who argued for that to
be introduced into pkgconfig to escape the mangling that we used to
do[1] ;-)

[1] We're literally in the process of removing that today.

Cheers,

Richard

Re: Missing includes in STAGING_INCDIR

[Tom Cooksey]

On Tuesday 04 March 2008 17:05:09 Richard Purdie wrote:
> On Tue, 2008-03-04 at 13:56 +0100, Tom Cooksey wrote:
> > Yup, we like pkgconfig too, saves us a lot of work. :-) Sadly, we have to support 
> > qt being built on 3rd party toolchains we have no access to and therefore no
> > way to modify. pkg-config caused a headache for support so we've dropped it
> > by default when cross-compiling. Hopefully we'll re-enable it in the future as
> > the pkg-config devs seem to be working on the problem, providing an env 
> > variable you can use to set a sysroot prefix (PKG_CONFIG_SYSROOT).
> 
> Just for reference, it was OE users (well, Poky) who argued for that to
> be introduced into pkgconfig to escape the mangling that we used to
> do[1] ;-)
> 
> [1] We're literally in the process of removing that today.

Awesome! Well argued. :-) Does that mean PKG_CONFIG_SYSROOT is stable
enough now to be used in anger?


Cheers,

Tom

Re: Missing includes in STAGING_INCDIR

[Richard Purdie]

On Tue, 2008-03-04 at 17:29 +0100, Tom Cooksey wrote:
> On Tuesday 04 March 2008 17:05:09 Richard Purdie wrote:
> > On Tue, 2008-03-04 at 13:56 +0100, Tom Cooksey wrote:
> > > Yup, we like pkgconfig too, saves us a lot of work. :-) Sadly, we have to support 
> > > qt being built on 3rd party toolchains we have no access to and therefore no
> > > way to modify. pkg-config caused a headache for support so we've dropped it
> > > by default when cross-compiling. Hopefully we'll re-enable it in the future as
> > > the pkg-config devs seem to be working on the problem, providing an env 
> > > variable you can use to set a sysroot prefix (PKG_CONFIG_SYSROOT).
> > 
> > Just for reference, it was OE users (well, Poky) who argued for that to
> > be introduced into pkgconfig to escape the mangling that we used to
> > do[1] ;-)
> > 
> > [1] We're literally in the process of removing that today.
> 
> Awesome! Well argued. :-) Does that mean PKG_CONFIG_SYSROOT is stable
> enough now to be used in anger?

Poky has been using it for a while without too many problems and OE has
just switched to it. It seems to work well although it does highlight
there are some badly written pkgconfig files around...

Cheers,

Richard