qt4e-demo-image with meta-fsl-arm: successful build?

qt4e-demo-image with meta-fsl-arm: successful build?

[Steve Sakoman]

Has anyone successfully built (and run!) the qt4e-demo-image with meta-fsl-arm?

I tried a build for a machine based on imx28evk and get a broken image
(i.e. demo fails to start at boot):

QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
Unable to load library icui18n "Cannot load library icui18n:
(libicui18n.so.36: cannot open shared object file: No such file or
directory)"
qtdemo: cannot connect to X server

Before I dig in and start debugging I thought I would check to see if
anyone else has had success with this layer/machine combo.

Thanks!

Steve

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Eric Bénard]

Le Sun, 9 Jun 2013 20:19:52 -0700,
Steve Sakoman <sakoman@gmail.com> a écrit :

> Has anyone successfully built (and run!) the qt4e-demo-image with meta-fsl-arm?
> 
> I tried a build for a machine based on imx28evk and get a broken image
> (i.e. demo fails to start at boot):
> 
> QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
> QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
> Unable to load library icui18n "Cannot load library icui18n:
> (libicui18n.so.36: cannot open shared object file: No such file or
> directory)"
> qtdemo: cannot connect to X server
> 
the strange thing is why do you get a X qtdemo when building
qt4e-demo-image ?
I've launched a build and will test on my imx28evk asap.

Eric

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Steve Sakoman]

On Mon, Jun 10, 2013 at 12:45 AM, Eric Bénard <eric@eukrea.com> wrote:

> the strange thing is why do you get a X qtdemo when building
> qt4e-demo-image ?

I haven't begun debugging yet, but I had 2 initial thoughts as to why
the X error message:

1. The qtdemo init seems to be written to support both x and x-free
setups, so perhaps the init is getting confused
2. I had built the x11-free version of qt prior to the qte version, so
perhaps that causes the issue

I started a clean build just in case #2 is the cause.

Steve

> I've launched a build and will test on my imx28evk asap.
>
> Eric

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Steve Sakoman]

And of course I should have mentioned in my first email that I am
using the danny branch of both repositories!

Steve

On Mon, Jun 10, 2013 at 5:58 AM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Mon, Jun 10, 2013 at 12:45 AM, Eric Bénard <eric@eukrea.com> wrote:
>
>> the strange thing is why do you get a X qtdemo when building
>> qt4e-demo-image ?
>
> I haven't begun debugging yet, but I had 2 initial thoughts as to why
> the X error message:
>
> 1. The qtdemo init seems to be written to support both x and x-free
> setups, so perhaps the init is getting confused
> 2. I had built the x11-free version of qt prior to the qte version, so
> perhaps that causes the issue
>
> I started a clean build just in case #2 is the cause.
>
> Steve
>
>> I've launched a build and will test on my imx28evk asap.
>>
>> Eric

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Eric Bénard]

Le Mon, 10 Jun 2013 05:58:42 -0700,
Steve Sakoman <sakoman@gmail.com> a écrit :

> On Mon, Jun 10, 2013 at 12:45 AM, Eric Bénard <eric@eukrea.com> wrote:
> 
> > the strange thing is why do you get a X qtdemo when building
> > qt4e-demo-image ?
> 
> I haven't begun debugging yet, but I had 2 initial thoughts as to why
> the X error message:
> 
> 1. The qtdemo init seems to be written to support both x and x-free
> setups, so perhaps the init is getting confused
> 2. I had built the x11-free version of qt prior to the qte version, so
> perhaps that causes the issue
> 
> I started a clean build just in case #2 is the cause.
> 
OK #2 is clearly a situation I avoid here as this created me some
troubles in the past.

Eric

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Steve Sakoman]

On Mon, Jun 10, 2013 at 6:07 AM, Eric Bénard <eric@eukrea.com> wrote:
> Le Mon, 10 Jun 2013 05:58:42 -0700,
> Steve Sakoman <sakoman@gmail.com> a écrit :
>> I haven't begun debugging yet, but I had 2 initial thoughts as to why
>> the X error message:
>>
>> 1. The qtdemo init seems to be written to support both x and x-free
>> setups, so perhaps the init is getting confused
>> 2. I had built the x11-free version of qt prior to the qte version, so
>> perhaps that causes the issue
>>
>> I started a clean build just in case #2 is the cause.
>>
> OK #2 is clearly a situation I avoid here as this created me some
> troubles in the past.

And it created issues for me too :-)

A clean build of qt4e-demo-image works.  A clean build of a similar
image based on qt4-x11-free however is broken as described in my
original post.

Clearly one must choose either qt4-x11-free or qt4e, having both in
the same build setup is broken (perhaps by design)

Steve

Re: qt4e-demo-image with meta-fsl-arm: successful build?

[Paul Eggleton]

On Monday 10 June 2013 08:43:38 Steve Sakoman wrote:
> On Mon, Jun 10, 2013 at 6:07 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Mon, 10 Jun 2013 05:58:42 -0700,
> > 
> > Steve Sakoman <sakoman@gmail.com> a écrit :
> >> I haven't begun debugging yet, but I had 2 initial thoughts as to why
> >> the X error message:
> >> 
> >> 1. The qtdemo init seems to be written to support both x and x-free
> >> setups, so perhaps the init is getting confused
> >> 2. I had built the x11-free version of qt prior to the qte version, so
> >> perhaps that causes the issue
> >> 
> >> I started a clean build just in case #2 is the cause.
> > 
> > OK #2 is clearly a situation I avoid here as this created me some
> > troubles in the past.
> 
> And it created issues for me too :-)
> 
> A clean build of qt4e-demo-image works.  A clean build of a similar
> image based on qt4-x11-free however is broken as described in my
> original post.
> 
> Clearly one must choose either qt4-x11-free or qt4e, having both in
> the same build setup is broken (perhaps by design)

I can say this is not by design. The two should be able to coexist (which is 
why the library names are different); if they currently cannot we need to figure 
out why that is and get it fixed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre