qmake issue

qmake issue

[Frans Meulenbroeks]

Hi,

I noticed the following issue when building mythtv.
Mythtv uses qmake. Several of the .pro files contain additional
libraries with -L

However if e.g. I look at the generated Makefile for mythfrontend I see:

LIBS          = $(SUBLIBS)  -L$(OE_QMAKE_LIBDIR_QT)
-Wl,-rpath-link,/home/frans/oe/tmp_angstrom/work/armv7a-angstrom-linux-gnueabi/qt4-x11-free-4.6.0-r13.1/qt-everywhere-opensource-src-4.6.0/lib
-L../../libs/libmyth -L../../libs/libmythtv -L../../libs/libavutil
-L../../libs/libavcodec -L../../libs/libavformat
-L../../libs/libswscale -L../../libs/libmythdb -L../../libs/libmythui
-L../../libs/libmythupnp -lmythtv-0.22 -lmythavformat-0.22
-lmythavutil-0.22 -lmythavcodec-0.22 -lmythswscale-0.22
-lmythupnp-0.22 -lmyth-0.22 -lmythui-0.22 -lmythdb-0.22
-L../../libs/libmythlivemedia -lmythlivemedia-0.22
-L../../libs/libmythfreemheg -lmythfreemheg-0.22
-L../../libs/libmythhdhomerun -lmythhdhomerun-0.22
-L/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
-lfreetype -lXinerama -lX11 -lXext -lXxf86vm -lXv -lXrandr -lQtWebKit
-Wl,-rpath-link,/usr/lib -lphonon -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -lQtDBus -Wl,-rpath-link,/usr/lib -lQtSql
-Wl,-rpath-link,/usr/lib -lQtXml -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -lQtGui -Wl,-rpath-link,/usr/lib -lQtNetwork
-Wl,-rpath-link,/usr/lib -lQtCore -Wl,-rpath-link,/usr/lib -lglib-2.0
-lpthread

and eventually the executed link command is:

ccache arm-angstrom-linux-gnueabi-g++
-L/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
-Wl,-rpath-link,/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
-Wl,-O1 -Wl,--hash-style=gnu -o mythfrontend version.o main.o
playbackbox.o viewscheduled.o globalsettings.o manualschedule.o
programrecpriority.o channelrecpriority.o statusbox.o networkcontrol.o
mediarenderer.o mythfexml.o playbackboxlistitem.o custompriority.o
mythappearance.o exitprompt.o proglist.o action.o actionset.o
mythcontrols.o keybindings.o keygrabber.o mythosdmenueditor.o
progfind.o guidegrid.o customedit.o schedulecommon.o progdetails.o
scheduleeditor.o moc_main.o moc_playbackbox.o moc_viewscheduled.o
moc_globalsettings.o moc_manualschedule.o moc_programrecpriority.o
moc_channelrecpriority.o moc_statusbox.o moc_networkcontrol.o
moc_custompriority.o moc_mythappearance.o moc_exitprompt.o
moc_proglist.o moc_mythcontrols.o moc_keygrabber.o
moc_mythosdmenueditor.o moc_progfind.o moc_guidegrid.o
moc_customedit.o moc_progdetails.o moc_scheduleeditor.o
-L/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
-Wl,-rpath-link,/home/frans/oe/tmp_angstrom/work/armv7a-angstrom-linux-gnueabi/qt4-x11-free-4.6.0-r13.1/qt-everywhere-opensource-src-4.6.0/lib
-L../../libs/libmyth -L../../libs/libmythtv -L../../libs/libavutil
-L../../libs/libavcodec -L../../libs/libavformat
-L../../libs/libswscale -L../../libs/libmythdb -L../../libs/libmythui
-L../../libs/libmythupnp -lmythtv-0.22 -lmythavformat-0.22
-lmythavutil-0.22 -lmythavcodec-0.22 -lmythswscale-0.22
-lmythupnp-0.22 -lmyth-0.22 -lmythui-0.22 -lmythdb-0.22
-L../../libs/libmythlivemedia -lmythlivemedia-0.22
-L../../libs/libmythfreemheg -lmythfreemheg-0.22
-L../../libs/libmythhdhomerun -lmythhdhomerun-0.22
-L/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
-lfreetype -lXinerama -lX11 -lXext -lXxf86vm -lXv -lXrandr -lQtWebKit
-Wl,-rpath-link,/usr/lib -lphonon -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib -lQtDBus
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -lQtSql -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib -lQtXml
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -lQtGui -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib -lQtNetwork
-Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/usr/lib
-Wl,-rpath-link,/usr/lib -lQtCore -Wl,-rpath-link,/usr/lib -lglib-2.0
-lpthread

In this I see two issues.

The obvious one is of course the explosion of  -Wl,-rpath-link,/usr/lib
Somewhat annoying but not really harmful.

What is more harmful though is that somewhere in the build process the
linking is done by invoking: arm-angstrom-linux-gnueabi-g++
-L/home/frans/oe/tmp_angstrom/staging/armv7a-angstrom-linux-gnueabi/usr/lib
...
-L dirs are searched for in the order they appear on the command line,
so the version in staging has preference above the local version
(which is only moved to staging after the compilation is completed).

I can imagine a few solutions, but no idea which one is the best and
how to implement them.
First option is to hack the generated makefile in a configure_append
step. While this would solve the issue for me it is not really a
generic solution.
Second option is to force removing a package from staging when a new
version is build
Third option is to change the class which generates the above command
to put the -L near the end (after any -L's from the makefile itself.

No idea on the way to solve this. Anyone an idea (and perhaps the
knowledge to fix this)?

Frans.

Re: qmake issue

[Phil Blundell]

On Sun, 2010-01-03 at 17:33 +0100, Frans Meulenbroeks wrote:
> I can imagine a few solutions, but no idea which one is the best and
> how to implement them.
> First option is to hack the generated makefile in a configure_append
> step. While this would solve the issue for me it is not really a
> generic solution.
> Second option is to force removing a package from staging when a new
> version is build
> Third option is to change the class which generates the above command
> to put the -L near the end (after any -L's from the makefile itself.

In the particular case of the myth* libraries, I think they should not
be getting staged in the first place.  As far as I know, no other
package uses them for anything.

However, that obviously doesn't solve your qmake problem in the general
case.  With a bit of luck some Qt hacker will be able to shed light on
what is really going on there.

p.

Re: qmake issue

[Frans Meulenbroeks]

2010/1/3 Phil Blundell <philb@gnu.org>:
> On Sun, 2010-01-03 at 17:33 +0100, Frans Meulenbroeks wrote:
>> I can imagine a few solutions, but no idea which one is the best and
>> how to implement them.
>> First option is to hack the generated makefile in a configure_append
>> step. While this would solve the issue for me it is not really a
>> generic solution.
>> Second option is to force removing a package from staging when a new
>> version is build
>> Third option is to change the class which generates the above command
>> to put the -L near the end (after any -L's from the makefile itself.
>
> In the particular case of the myth* libraries, I think they should not
> be getting staged in the first place.  As far as I know, no other
> package uses them for anything.
>
> However, that obviously doesn't solve your qmake problem in the general
> case.  With a bit of luck some Qt hacker will be able to shed light on
> what is really going on there.

Yeah figured out after a brief discussion on #oe that they probably
didn't need to be staged.

Actually the recipe does not contain any staging, so this is a side
effect of the new automated staging.
It could well be that other,  non qmake recipes also suffer from this.

The fix for mythtv is probably to have an empty do_stage()

However as a general rule the -L and -I flags to staging should be
last, not first.
And, ideally, when building a recipe the old contents from that
package in staging should be removed first.
By removing that we avoid the problem that if rX adds a file A to
staging and rY does not do so any more, the file A still remains in
staging (although perhaps incompatible with what rY made.

Frans

Re: qmake issue

[Richard Purdie]

On Mon, 2010-01-04 at 08:31 +0100, Frans Meulenbroeks wrote:
> Yeah figured out after a brief discussion on #oe that they probably
> didn't need to be staged.
> 
> Actually the recipe does not contain any staging, so this is a side
> effect of the new automated staging.
> It could well be that other,  non qmake recipes also suffer from this.
> 
> The fix for mythtv is probably to have an empty do_stage()
> 
> However as a general rule the -L and -I flags to staging should be
> last, not first.
> And, ideally, when building a recipe the old contents from that
> package in staging should be removed first.
> By removing that we avoid the problem that if rX adds a file A to
> staging and rY does not do so any more, the file A still remains in
> staging (although perhaps incompatible with what rY made.

If packaged staging is enabled this should happen already...

Cheers,

Richard

Re: qmake issue

[Frans Meulenbroeks]

2010/1/4 Richard Purdie <rpurdie@rpsys.net>:
> On Mon, 2010-01-04 at 08:31 +0100, Frans Meulenbroeks wrote:
>> Yeah figured out after a brief discussion on #oe that they probably
>> didn't need to be staged.
>>
>> Actually the recipe does not contain any staging, so this is a side
>> effect of the new automated staging.
>> It could well be that other,  non qmake recipes also suffer from this.
>>
>> The fix for mythtv is probably to have an empty do_stage()
>>
>> However as a general rule the -L and -I flags to staging should be
>> last, not first.
>> And, ideally, when building a recipe the old contents from that
>> package in staging should be removed first.
>> By removing that we avoid the problem that if rX adds a file A to
>> staging and rY does not do so any more, the file A still remains in
>> staging (although perhaps incompatible with what rY made.
>
> If packaged staging is enabled this should happen already...
>
> Cheers,
>
> Richard
>
Ehm, I use angstrom unstable head on the beagleboard.I've been told on
#oe that angstrom used pacakged staging.
I've removed my tmp dir and rebuild from scratch on dec 30, 2009,
including mythtv.
Yesterday I rebuild the latest version of mythtv, and it linked
against the myth lib in staging (produced by the same recipe).
As the lib was changed between those versions it gave a linking error.
After removing the lib from staging manually and rebuilding mythtv
builds properly.
To me this seems there is still a problem.

Frans.

Re: qmake issue

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04-01-10 21:14, Frans Meulenbroeks wrote:
> 2010/1/4 Richard Purdie <rpurdie@rpsys.net>:
>> On Mon, 2010-01-04 at 08:31 +0100, Frans Meulenbroeks wrote:
>>> Yeah figured out after a brief discussion on #oe that they probably
>>> didn't need to be staged.
>>>
>>> Actually the recipe does not contain any staging, so this is a side
>>> effect of the new automated staging.
>>> It could well be that other,  non qmake recipes also suffer from this.
>>>
>>> The fix for mythtv is probably to have an empty do_stage()
>>>
>>> However as a general rule the -L and -I flags to staging should be
>>> last, not first.
>>> And, ideally, when building a recipe the old contents from that
>>> package in staging should be removed first.
>>> By removing that we avoid the problem that if rX adds a file A to
>>> staging and rY does not do so any more, the file A still remains in
>>> staging (although perhaps incompatible with what rY made.
>>
>> If packaged staging is enabled this should happen already...
>>
>> Cheers,
>>
>> Richard
>>
> Ehm, I use angstrom unstable head on the beagleboard.I've been told on
> #oe that angstrom used pacakged staging.
> I've removed my tmp dir and rebuild from scratch on dec 30, 2009,
> including mythtv.
> Yesterday I rebuild the latest version of mythtv, and it linked
> against the myth lib in staging (produced by the same recipe).
> As the lib was changed between those versions it gave a linking error.
> After removing the lib from staging manually and rebuilding mythtv
> builds properly.
> To me this seems there is still a problem.

Packaged-staging only works if you have built opkg-native, otherwise it
won't remove things from staging. The problem is that you can't to
'bitbake opkg-native' twice, so the angstrom buildscripts now do:
http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=org.openembedded.dev&id=6fb8200b0002fad7ed4b67b7b5a01a54bc3db91c

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLQlBWMkyGM64RGpERAtFbAJ9bzOb4XvpCme4V2E9t8ER9tYcVsACcC7nq
qqFJxVxAQKpndDkZeEANHe0=
=AvU+
-----END PGP SIGNATURE-----

Re: qmake issue

[Frans Meulenbroeks]

2010/1/4 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04-01-10 21:14, Frans Meulenbroeks wrote:
>> 2010/1/4 Richard Purdie <rpurdie@rpsys.net>:
>>> On Mon, 2010-01-04 at 08:31 +0100, Frans Meulenbroeks wrote:
>>>> Yeah figured out after a brief discussion on #oe that they probably
>>>> didn't need to be staged.
>>>>
>>>> Actually the recipe does not contain any staging, so this is a side
>>>> effect of the new automated staging.
>>>> It could well be that other,  non qmake recipes also suffer from this.
>>>>
>>>> The fix for mythtv is probably to have an empty do_stage()
>>>>
>>>> However as a general rule the -L and -I flags to staging should be
>>>> last, not first.
>>>> And, ideally, when building a recipe the old contents from that
>>>> package in staging should be removed first.
>>>> By removing that we avoid the problem that if rX adds a file A to
>>>> staging and rY does not do so any more, the file A still remains in
>>>> staging (although perhaps incompatible with what rY made.
>>>
>>> If packaged staging is enabled this should happen already...
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>> Ehm, I use angstrom unstable head on the beagleboard.I've been told on
>> #oe that angstrom used pacakged staging.
>> I've removed my tmp dir and rebuild from scratch on dec 30, 2009,
>> including mythtv.
>> Yesterday I rebuild the latest version of mythtv, and it linked
>> against the myth lib in staging (produced by the same recipe).
>> As the lib was changed between those versions it gave a linking error.
>> After removing the lib from staging manually and rebuilding mythtv
>> builds properly.
>> To me this seems there is still a problem.
>
> Packaged-staging only works if you have built opkg-native, otherwise it
> won't remove things from staging. The problem is that you can't to
> 'bitbake opkg-native' twice, so the angstrom buildscripts now do:
> http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=org.openembedded.dev&id=6fb8200b0002fad7ed4b67b7b5a01a54bc3db91c
>
> regards,
>
> Koen


Ah ok, understood, Should opkg-native then not be build in the
beginning of the build process?
I would like to see it build automatically next time I rm my tmp dir...


Frans