[Buildroot] Currently packaging Qt5

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Hello,

This is just a quick note to let people know that I've started
packaging Qt5. I'm re-using existing packaging efforts done by
RasberryPi folks, and I'm already quite far in the process. I hope to
be able to post something soon.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Daniel Nyström]

Very appreciated! Do you know if there is OpenGL support for i.e. OMAP
(PowerVR) in Buildroot and, if that's the case, will Qt5 make use of that?

I once started with a PowerVR package for BR, but got interrupted and never
had time to catch up. :/



On Mon, Jan 14, 2013 at 10:58 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> This is just a quick note to let people know that I've started
> packaging Qt5. I'm re-using existing packaging efforts done by
> RasberryPi folks, and I'm already quite far in the process. I hope to
> be able to post something soon.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130114/65366fd6/attachment-0001.html>

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Daniel Nystr?m,

On Mon, 14 Jan 2013 11:50:48 +0100, Daniel Nystr?m wrote:
> Very appreciated! Do you know if there is OpenGL support for i.e. OMAP
> (PowerVR) in Buildroot and, if that's the case, will Qt5 make use of that?
> 
> I once started with a PowerVR package for BR, but got interrupted and never
> had time to catch up. :/

For now, I have added support for the eglfs backend of Qt5, by using
the OpenGLESv2 and EGL implementations for the RasberryPi. I've also
added in the process virtual packages for libglesv2, libegl and
libopenvg, so that multiple implementations can be packaged for those
APIs.

However, I haven't looked at packaging the OMAP PowerVR stuff for now.
So if anyone wants to have a look, would be nice.

I currently have https://github.com/prabindh/sgxconfiguro (a set of
pkg-config files that apparently make it a bit easier to use the SGX
stuff), and http://gpupowered.org/node/8 opened in my browser, as
useful links regarding SGX stuff. Just in case someone wants to start
working on this.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

On below - how can I help ? Note that sgxconfiguro, while useful in
autoconfigure for egl/gles2, for Qt5 is not especially useful as it fails
because of missing icu detection via autoconfig. So I reverted back to
regular configurations via qmake.conf at this time.



Thomas Petazzoni-2 wrote
> Dear Daniel Nystr?m,
> 
> On Mon, 14 Jan 2013 11:50:48 +0100, Daniel Nystr?m wrote:
>> Very appreciated! Do you know if there is OpenGL support for i.e. OMAP
>> (PowerVR) in Buildroot and, if that's the case, will Qt5 make use of
>> that?
>> 
>> I once started with a PowerVR package for BR, but got interrupted and
>> never
>> had time to catch up. :/
> 
> For now, I have added support for the eglfs backend of Qt5, by using
> the OpenGLESv2 and EGL implementations for the RasberryPi. I've also
> added in the process virtual packages for libglesv2, libegl and
> libopenvg, so that multiple implementations can be packaged for those
> APIs.
> 
> However, I haven't looked at packaging the OMAP PowerVR stuff for now.
> So if anyone wants to have a look, would be nice.
> 
> I currently have https://github.com/prabindh/sgxconfiguro (a set of
> pkg-config files that apparently make it a bit easier to use the SGX
> stuff), and http://gpupowered.org/node/8 opened in my browser, as
> useful links regarding SGX stuff. Just in case someone wants to start
> working on this.
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list

> buildroot@

> http://lists.busybox.net/mailman/listinfo/buildroot





--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p40702.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Hello prabindh,

On Mon, 18 Feb 2013 20:18:49 -0800 (PST), prabindh wrote:

> On below - how can I help ? Note that sgxconfiguro, while useful in
> autoconfigure for egl/gles2, for Qt5 is not especially useful as it
> fails because of missing icu detection via autoconfig. So I reverted
> back to regular configurations via qmake.conf at this time.

If you're interested in Buildroot, the best way you can help is by
creating packages for the SGX stuff needed to bring OpenGL support on
OMAP platforms. That would definitely be useful.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

Using default cross-compiled toolchain for the Beaglebone, some of the Xorg
libraries are failing to link, with below errors:

undefined reference to `pwrite64'
undefined reference to `pread64'

Looks like a fix is needed as per below threads - Can you please confirm
what is the right approach here ?

http://lists.uclibc.org/pipermail/uclibc/2013-January/047415.html
http://git.uclibc.org/uClibc/commit/?id=a586f419f5195ee5d7cb69c9c40263e01aec42


I need C++ toolchain as well, that does not seem to be built with buildroot
by default. Are the below the right set of options to add to have this
support ?

"BR2_GCC_CROSS_CXX=y BR2_INSTALL_LIBSTDCPP=y"

regards,
prabu



Thomas Petazzoni-2 wrote
> Hello prabindh,
> 
> On Mon, 18 Feb 2013 20:18:49 -0800 (PST), prabindh wrote:
> 
>> On below - how can I help ? Note that sgxconfiguro, while useful in
>> autoconfigure for egl/gles2, for Qt5 is not especially useful as it
>> fails because of missing icu detection via autoconfig. So I reverted
>> back to regular configurations via qmake.conf at this time.
> 
> If you're interested in Buildroot, the best way you can help is by
> creating packages for the SGX stuff needed to bring OpenGL support on
> OMAP platforms. That would definitely be useful.
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list

> buildroot@

> http://lists.busybox.net/mailman/listinfo/buildroot





--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45544.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Currently packaging Qt5

[Sundareson, Prabindh]

Hello Thomas,

Any advice on below post ?

This is for building the SGX Graphics drivers with BR. 

regards,
Prabindh


-----Original Message-----
From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of Sundareson, Prabindh
Sent: Monday, May 20, 2013 9:02 AM
To: buildroot at busybox.net
Subject: Re: [Buildroot] Currently packaging Qt5

Hello Thomas,

Using default cross-compiled toolchain for the Beaglebone, some of the Xorg libraries are failing to link, with below errors:

undefined reference to `pwrite64'
undefined reference to `pread64'

Looks like a fix is needed as per below threads - Can you please confirm what is the right approach here ?

http://lists.uclibc.org/pipermail/uclibc/2013-January/047415.html
http://git.uclibc.org/uClibc/commit/?id=a586f419f5195ee5d7cb69c9c40263e01aec42


I need C++ toolchain as well, that does not seem to be built with buildroot by default. Are the below the right set of options to add to have this support ?

"BR2_GCC_CROSS_CXX=y BR2_INSTALL_LIBSTDCPP=y"

regards,
prabu



Thomas Petazzoni-2 wrote
> Hello prabindh,
> 
> On Mon, 18 Feb 2013 20:18:49 -0800 (PST), prabindh wrote:
> 
>> On below - how can I help ? Note that sgxconfiguro, while useful in 
>> autoconfigure for egl/gles2, for Qt5 is not especially useful as it 
>> fails because of missing icu detection via autoconfig. So I reverted 
>> back to regular configurations via qmake.conf at this time.
> 
> If you're interested in Buildroot, the best way you can help is by 
> creating packages for the SGX stuff needed to bring OpenGL support on 
> OMAP platforms. That would definitely be useful.
> 
> Best regards,
> 
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux development, consulting, 
> training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list

> buildroot@

> http://lists.busybox.net/mailman/listinfo/buildroot





--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45544.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Sundareson, Prabindh,

On Wed, 22 May 2013 11:55:33 +0000, Sundareson, Prabindh wrote:

> Any advice on below post ?

I've just replied to you, sorry for the delay.

> This is for building the SGX Graphics drivers with BR. 

Note that we have a GSoC student this year, Spenser Gilliland, who will
work on adding support in Buildroot for OpenGL and other similar/related
technologies for various ARM SoCs. So packaging the SGX stuff to
support OpenGL on OMAP is part of this GSoC TODO list.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

So after the driver package is rebuilt (and hosted somewhere), he can use this to create the recipe ? That would be good.

>> So packaging the SGX stuff to support OpenGL on OMAP is part of this GSoC TODO list.

regards,
Prabindh



From: Thomas Petazzoni-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45656h39 at n4.nabble.com] 
Sent: Wednesday, May 22, 2013 5:48 PM
To: Sundareson, Prabindh
Subject: Re: Currently packaging Qt5

Dear Sundareson, Prabindh, 

On Wed, 22 May 2013 11:55:33 +0000, Sundareson, Prabindh wrote: 

> Any advice on below post ? 

I've just replied to you, sorry for the delay. 

> This is for building the SGX Graphics drivers with BR. 

Note that we have a GSoC student this year, Spenser Gilliland, who will 
work on adding support in Buildroot for OpenGL and other similar/related 
technologies for various ARM SoCs. So packaging the SGX stuff to 
support OpenGL on OMAP is part of this GSoC TODO list. 

Best regards, 

Thomas 
-- 
Thomas Petazzoni, Free Electrons 
Kernel, drivers, real-time and embedded Linux 
development, consulting, training and support. 
http://free-electrons.com
_______________________________________________ 
buildroot mailing list 
[hidden email] 
http://lists.busybox.net/mailman/listinfo/buildroot

________________________________________
If you reply to this email, your message will be added to the discussion below:
http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45656.html 
To unsubscribe from Currently packaging Qt5, click here.
NAML 




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45659.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130522/dc0fb291/attachment.html>

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear prabindh,

On Wed, 22 May 2013 05:23:08 -0700 (PDT), prabindh wrote:

> So after the driver package is rebuilt (and hosted somewhere), he can
> use this to create the recipe ? That would be good.

I'm not sure to follow you here. The necessary drivers and libraries to
enable OpenGL on OMAP are already available. So what Spenser will work
on is creating recipes for those software components, so that Buildroot
users can easily get OpenGL support on OMAP platforms.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

Ok - I expected that the hardfp movement (in the current SGX Graphics driver) would have caused ABI conflicts with buildroot systems. Has anyone tested compatibility ?

regards,
Prabindh

From: Thomas Petazzoni-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45662h25 at n4.nabble.com] 
Sent: Wednesday, May 22, 2013 6:02 PM
To: Sundareson, Prabindh
Subject: Re: Currently packaging Qt5

Dear prabindh, 

On Wed, 22 May 2013 05:23:08 -0700 (PDT), prabindh wrote: 

> So after the driver package is rebuilt (and hosted somewhere), he can 
> use this to create the recipe ? That would be good. 

I'm not sure to follow you here. The necessary drivers and libraries to 
enable OpenGL on OMAP are already available. So what Spenser will work 
on is creating recipes for those software components, so that Buildroot 
users can easily get OpenGL support on OMAP platforms. 

Best regards, 

Thomas 
-- 
Thomas Petazzoni, Free Electrons 
Kernel, drivers, real-time and embedded Linux 
development, consulting, training and support. 
http://free-electrons.com
_______________________________________________ 
buildroot mailing list 
[hidden email] 
http://lists.busybox.net/mailman/listinfo/buildroot

________________________________________
If you reply to this email, your message will be added to the discussion below:
http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45662.html 
To unsubscribe from Currently packaging Qt5, click here.
NAML 




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45663.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130522/56a8ad42/attachment.html>

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear prabindh,

On Wed, 22 May 2013 05:36:02 -0700 (PDT), prabindh wrote:

> Ok - I expected that the hardfp movement (in the current SGX Graphics
> driver) would have caused ABI conflicts with buildroot systems. Has
> anyone tested compatibility ?

Since most of the libraries needed to support OpenGL on various SoC are
delivered binary-only, there will certainly be a work to define with
which toolchain/C library such libraries are compatible. That's more
work on Spenser's plate :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Sundareson, Prabindh]

Hello Thomas

Ok. What I really meant is - I am "rebuilding" the drivers with the Buildroot toolchain (so, potentially there will be a newer binary package exclusively for Buildroot). With these new drivers, will Spenser be able to create the required recipe ?

regards,
Prabindh


-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com] 
Sent: Wednesday, May 22, 2013 6:37 PM
To: Sundareson, Prabindh
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Currently packaging Qt5

Dear prabindh,

On Wed, 22 May 2013 05:36:02 -0700 (PDT), prabindh wrote:

> Ok - I expected that the hardfp movement (in the current SGX Graphics
> driver) would have caused ABI conflicts with buildroot systems. Has
> anyone tested compatibility ?

Since most of the libraries needed to support OpenGL on various SoC are
delivered binary-only, there will certainly be a work to define with
which toolchain/C library such libraries are compatible. That's more
work on Spenser's plate :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Sundareson, Prabindh,

On Wed, 22 May 2013 13:26:53 +0000, Sundareson, Prabindh wrote:

> Ok. What I really meant is - I am "rebuilding" the drivers with the
> Buildroot toolchain (so, potentially there will be a newer binary
> package exclusively for Buildroot). With these new drivers, will
> Spenser be able to create the required recipe ?

When you mean "drivers", do you mean the kernel drivers or the
userspace libraries? As far as I know, the kernel drivers are
open-source, so anyone can rebuild them.

However, the userspace libraries are binary-only. Of course, it appears
that you work at TI, so maybe you have access to the source code of
those userspace libraries that are, for us mere mortals, binary-only.

If it's the case, rebuilding them with the Buildroot toolchain and
providing us with the resulting binary would not make much sense
unfortunately: the uClibc library that Buildroot uses in its internal
toolchain backend does not provide any kind of backward compatible ABI.
So whenever the uClibc version or configuration is changed, the ABI
might be broken. So using binary-only userspace libraries in an uClibc
context is particularly difficult, I'm afraid.

Or maybe you're talking about something else?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

Yes, I am talking about rebuilding the userspace libraries. I deliver the Graphics drivers for SGX.

The aspect of uclibc breaking compatibility was not clear to me earlier. How do you plan to support "any" closed source packages then ? Why cant we have backward compatibility in uclibc ?

regards,
Prabu

From: Thomas Petazzoni-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45666h49 at n4.nabble.com]
Sent: Wednesday, May 22, 2013 7:01 PM
To: Sundareson, Prabindh
Subject: Re: Currently packaging Qt5

Dear Sundareson, Prabindh,

On Wed, 22 May 2013 13:26:53 +0000, Sundareson, Prabindh wrote:

> Ok. What I really meant is - I am "rebuilding" the drivers with the
> Buildroot toolchain (so, potentially there will be a newer binary
> package exclusively for Buildroot). With these new drivers, will
> Spenser be able to create the required recipe ?

When you mean "drivers", do you mean the kernel drivers or the
userspace libraries? As far as I know, the kernel drivers are
open-source, so anyone can rebuild them.

However, the userspace libraries are binary-only. Of course, it appears
that you work at TI, so maybe you have access to the source code of
those userspace libraries that are, for us mere mortals, binary-only.

If it's the case, rebuilding them with the Buildroot toolchain and
providing us with the resulting binary would not make much sense
unfortunately: the uClibc library that Buildroot uses in its internal
toolchain backend does not provide any kind of backward compatible ABI.
So whenever the uClibc version or configuration is changed, the ABI
might be broken. So using binary-only userspace libraries in an uClibc
context is particularly difficult, I'm afraid.

Or maybe you're talking about something else?

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
[hidden email]</user/SendEmail.jtp?type=node&node=45666&i=0>
http://lists.busybox.net/mailman/listinfo/buildroot

________________________________
If you reply to this email, your message will be added to the discussion below:
http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45666.html
To unsubscribe from Currently packaging Qt5, click here<http://buildroot-busybox.2317881.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=38584&code=cHJhYnVAdGkuY29tfDM4NTg0fDE0OTk5ODQwMzg=>.
NAML<http://buildroot-busybox.2317881.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45668.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130522/f2c32a7a/attachment.html>

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear prabindh,

On Wed, 22 May 2013 06:35:55 -0700 (PDT), prabindh wrote:

> Yes, I am talking about rebuilding the userspace libraries. I deliver
> the Graphics drivers for SGX.

Ah, nice to have you on board then :-) We may certainly have questions
as we integrate those libraries in Buildroot.

> The aspect of uclibc breaking compatibility was not clear to me
> earlier. How do you plan to support "any" closed source packages
> then ?

With (e)glibc libraries, that we support through the external toolchain
mechanism.

> Why cant we have backward compatibility in uclibc ?

I am not sure how accurate
https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt
is, must it says:

"""
3) uClibc does not even attempt to ensure binary compatibility across
releases. When a new version of uClibc is released, you may or may not
need to recompile all your binaries.
"""

That said, the uClibc web site, at http://www.uclibc.org/oldnews.html,
says:

"""
Please be aware we will break binary compatibilty in the upcoming
0.9.27 release to implement a few necessary changes we have been
postponing. That will hopefully be the last ABI change before we freeze
the ABI for the upcoming 1.0.x stable uClibc series. 
"""

So it looks like there was some intention about having a stable ABI at
some point. But this news was from 2004, and the 1.0.x stable uClibc
series still hasn't been released, 9 years later.

Maybe other people can comment? Or maybe we should bring the issue to
the uClibc developers and see what they say?

In the mean time, my expectation is that we will be using all those
binary-only libraries on top of glibc/eglibc only. If you're doing some
crazy OpenGL multimedia stuff, you can anyway afford the comparatively
small additional cost of using glibc/eglibc in your embedded Linux
system.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Spenser Gilliland]

Prabu & Thomas,

I was actually working on this last night!  As a resource I am using
the ti-meta overlay from
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb
.  I can download and build the driver (kinda of messy), but I haven't
tested it yet.  You can see the progress on my Github.

I've automated the license acceptance as well as the sgx driver build.
 Still working on the rest.

Spenser

On Wed, May 22, 2013 at 9:04 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear prabindh,
>
> On Wed, 22 May 2013 06:35:55 -0700 (PDT), prabindh wrote:
>
>> Yes, I am talking about rebuilding the userspace libraries. I deliver
>> the Graphics drivers for SGX.
>
> Ah, nice to have you on board then :-) We may certainly have questions
> as we integrate those libraries in Buildroot.
>
>> The aspect of uclibc breaking compatibility was not clear to me
>> earlier. How do you plan to support "any" closed source packages
>> then ?
>
> With (e)glibc libraries, that we support through the external toolchain
> mechanism.
>
>> Why cant we have backward compatibility in uclibc ?
>
> I am not sure how accurate
> https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt
> is, must it says:
>
> """
> 3) uClibc does not even attempt to ensure binary compatibility across
> releases. When a new version of uClibc is released, you may or may not
> need to recompile all your binaries.
> """
>
> That said, the uClibc web site, at http://www.uclibc.org/oldnews.html,
> says:
>
> """
> Please be aware we will break binary compatibilty in the upcoming
> 0.9.27 release to implement a few necessary changes we have been
> postponing. That will hopefully be the last ABI change before we freeze
> the ABI for the upcoming 1.0.x stable uClibc series.
> """
>
> So it looks like there was some intention about having a stable ABI at
> some point. But this news was from 2004, and the 1.0.x stable uClibc
> series still hasn't been released, 9 years later.
>
> Maybe other people can comment? Or maybe we should bring the issue to
> the uClibc developers and see what they say?
>
> In the mean time, my expectation is that we will be using all those
> binary-only libraries on top of glibc/eglibc only. If you're doing some
> crazy OpenGL multimedia stuff, you can anyway afford the comparatively
> small additional cost of using glibc/eglibc in your embedded Linux
> system.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Spenser Gilliland
Computer Engineer
Doctoral Candidate

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Spenser Gilliland,

On Wed, 22 May 2013 09:18:36 -0500, Spenser Gilliland wrote:

> I was actually working on this last night!  As a resource I am using
> the ti-meta overlay from
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb
> .  I can download and build the driver (kinda of messy), but I haven't
> tested it yet.  You can see the progress on my Github.
> 
> I've automated the license acceptance as well as the sgx driver build.
>  Still working on the rest.

Nice!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

The recipe will be upgraded to the below - I just submitted revised patchset:  So please keep that in mind when building your recipe. The new recipe removes lot of unsupported old features, and generally cleans up the rest.

http://comments.gmane.org/gmane.linux.embedded.yocto.meta-ti/1946

regards,
Prabu

From: Spenser Gilliland-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45674h97 at n4.nabble.com]
Sent: Wednesday, May 22, 2013 8:10 PM
To: Sundareson, Prabindh
Subject: Re: Currently packaging Qt5

Prabu & Thomas,

I was actually working on this last night!  As a resource I am using
the ti-meta overlay from
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb
.  I can download and build the driver (kinda of messy), but I haven't
tested it yet.  You can see the progress on my Github.

I've automated the license acceptance as well as the sgx driver build.
 Still working on the rest.

Spenser

On Wed, May 22, 2013 at 9:04 AM, Thomas Petazzoni
<[hidden email]</user/SendEmail.jtp?type=node&node=45674&i=0>> wrote:

> Dear prabindh,
>
> On Wed, 22 May 2013 06:35:55 -0700 (PDT), prabindh wrote:
>
>> Yes, I am talking about rebuilding the userspace libraries. I deliver
>> the Graphics drivers for SGX.
>
> Ah, nice to have you on board then :-) We may certainly have questions
> as we integrate those libraries in Buildroot.
>
>> The aspect of uclibc breaking compatibility was not clear to me
>> earlier. How do you plan to support "any" closed source packages
>> then ?
>
> With (e)glibc libraries, that we support through the external toolchain
> mechanism.
>
>> Why cant we have backward compatibility in uclibc ?
>
> I am not sure how accurate
> https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt
> is, must it says:
>
> """
> 3) uClibc does not even attempt to ensure binary compatibility across
> releases. When a new version of uClibc is released, you may or may not
> need to recompile all your binaries.
> """
>
> That said, the uClibc web site, at http://www.uclibc.org/oldnews.html,
> says:
>
> """
> Please be aware we will break binary compatibilty in the upcoming
> 0.9.27 release to implement a few necessary changes we have been
> postponing. That will hopefully be the last ABI change before we freeze
> the ABI for the upcoming 1.0.x stable uClibc series.
> """
>
> So it looks like there was some intention about having a stable ABI at
> some point. But this news was from 2004, and the 1.0.x stable uClibc
> series still hasn't been released, 9 years later.
>
> Maybe other people can comment? Or maybe we should bring the issue to
> the uClibc developers and see what they say?
>
> In the mean time, my expectation is that we will be using all those
> binary-only libraries on top of glibc/eglibc only. If you're doing some
> crazy OpenGL multimedia stuff, you can anyway afford the comparatively
> small additional cost of using glibc/eglibc in your embedded Linux
> system.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> [hidden email]</user/SendEmail.jtp?type=node&node=45674&i=1>
> http://lists.busybox.net/mailman/listinfo/buildroot



--
Spenser Gilliland
Computer Engineer
Doctoral Candidate
_______________________________________________
buildroot mailing list
[hidden email]</user/SendEmail.jtp?type=node&node=45674&i=2>
http://lists.busybox.net/mailman/listinfo/buildroot

________________________________
If you reply to this email, your message will be added to the discussion below:
http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45674.html
To unsubscribe from Currently packaging Qt5, click here<http://buildroot-busybox.2317881.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=38584&code=cHJhYnVAdGkuY29tfDM4NTg0fDE0OTk5ODQwMzg=>.
NAML<http://buildroot-busybox.2317881.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45683.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130522/0492ecc3/attachment-0001.html>

[Buildroot] Currently packaging Qt5

[Spenser Gilliland]

Thanks pointing me at these new patches.

Spenser

On Wed, May 22, 2013 at 10:57 AM, prabindh <prabu@ti.com> wrote:
> The recipe will be upgraded to the below ? I just submitted revised
> patchset:  So please keep that in mind when building your recipe. The new
> recipe removes lot of unsupported old features, and generally cleans up the
> rest.
>
>
>
> http://comments.gmane.org/gmane.linux.embedded.yocto.meta-ti/1946
>
>
>
> regards,
>
> Prabu
>
>
>
> From: Spenser Gilliland-2 [via Buildroot (busybox)] [mailto:ml-node+[hidden
> email]]
> Sent: Wednesday, May 22, 2013 8:10 PM
>
>
> To: Sundareson, Prabindh
> Subject: Re: Currently packaging Qt5
>
>
>
> Prabu & Thomas,
>
>
> I was actually working on this last night!  As a resource I am using
> the ti-meta overlay from
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb
> .  I can download and build the driver (kinda of messy), but I haven't
> tested it yet.  You can see the progress on my Github.
>
> I've automated the license acceptance as well as the sgx driver build.
>  Still working on the rest.
>
> Spenser
>
> On Wed, May 22, 2013 at 9:04 AM, Thomas Petazzoni
> <[hidden email]> wrote:
>
>
>> Dear prabindh,
>>
>> On Wed, 22 May 2013 06:35:55 -0700 (PDT), prabindh wrote:
>>
>>> Yes, I am talking about rebuilding the userspace libraries. I deliver
>>> the Graphics drivers for SGX.
>>
>> Ah, nice to have you on board then :-) We may certainly have questions
>> as we integrate those libraries in Buildroot.
>>
>>> The aspect of uclibc breaking compatibility was not clear to me
>>> earlier. How do you plan to support "any" closed source packages
>>> then ?
>>
>> With (e)glibc libraries, that we support through the external toolchain
>> mechanism.
>>
>>> Why cant we have backward compatibility in uclibc ?
>>
>> I am not sure how accurate
>>
>> https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt
>> is, must it says:
>>
>> """
>> 3) uClibc does not even attempt to ensure binary compatibility across
>> releases. When a new version of uClibc is released, you may or may not
>> need to recompile all your binaries.
>> """
>>
>> That said, the uClibc web site, at http://www.uclibc.org/oldnews.html,
>> says:
>>
>> """
>> Please be aware we will break binary compatibilty in the upcoming
>> 0.9.27 release to implement a few necessary changes we have been
>> postponing. That will hopefully be the last ABI change before we freeze
>> the ABI for the upcoming 1.0.x stable uClibc series.
>> """
>>
>> So it looks like there was some intention about having a stable ABI at
>> some point. But this news was from 2004, and the 1.0.x stable uClibc
>> series still hasn't been released, 9 years later.
>>
>> Maybe other people can comment? Or maybe we should bring the issue to
>> the uClibc developers and see what they say?
>>
>> In the mean time, my expectation is that we will be using all those
>> binary-only libraries on top of glibc/eglibc only. If you're doing some
>> crazy OpenGL multimedia stuff, you can anyway afford the comparatively
>> small additional cost of using glibc/eglibc in your embedded Linux
>> system.
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
>> _______________________________________________
>> buildroot mailing list
>> [hidden email]
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
>
>
> --
> Spenser Gilliland
> Computer Engineer
> Doctoral Candidate
> _______________________________________________
> buildroot mailing list
> [hidden email]
> http://lists.busybox.net/mailman/listinfo/buildroot
>
> ________________________________
>
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45674.html
>
> To unsubscribe from Currently packaging Qt5, click here.
> NAML
>
>
> ________________________________
> View this message in context: RE: Currently packaging Qt5
> Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Spenser Gilliland
Computer Engineer
Doctoral Candidate

[Buildroot] Currently packaging Qt5

[Wojciech Sleńska]

Hello Spenser,

I already have full OpenGL ES support on my TI AM3517 in QT5 using eglfs plugin.

I use following half-manual procedure to made this:
1. I build kernel modules using TI Graphics_SDK_4_09_00_01 package,
downloaded from TI page
2. I made some changes in qt5 build scripts in buildroot and add path to ti libs

config BR2_PACKAGE_QT_OMAP_LIB_PATH
   depends on BR2_PACKAGE_QT_OMAP_OPENGL
   string "Gr lib patch (ex. /home/wojtek/Graphics_SDK_4_09_00_01)"

As compiler I use arago-2011.09 with following flags -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp

3. When build is finished. I copy some files from
Graphics_SDK_4_09_00_01/gfx_rel_es3.x/ directory to target rootfs.
4. Now I can run ./hellogl_es2 -platform eglfs

I can send you my patches for qt5 package if you want. I can also test
your solution/proposals on my board.

Best Regards
Wojciech Slenska


2013/5/22 Spenser Gilliland <spenser@gillilanding.com>:
> Thanks pointing me at these new patches.
>
> Spenser
>
> On Wed, May 22, 2013 at 10:57 AM, prabindh <prabu@ti.com> wrote:
>> The recipe will be upgraded to the below ? I just submitted revised
>> patchset:  So please keep that in mind when building your recipe. The new
>> recipe removes lot of unsupported old features, and generally cleans up the
>> rest.
>>
>>
>>
>> http://comments.gmane.org/gmane.linux.embedded.yocto.meta-ti/1946
>>
>>
>>
>> regards,
>>
>> Prabu
>>
>>
>>
>> From: Spenser Gilliland-2 [via Buildroot (busybox)] [mailto:ml-node+[hidden
>> email]]
>> Sent: Wednesday, May 22, 2013 8:10 PM
>>
>>
>> To: Sundareson, Prabindh
>> Subject: Re: Currently packaging Qt5
>>
>>
>>
>> Prabu & Thomas,
>>
>>
>> I was actually working on this last night!  As a resource I am using
>> the ti-meta overlay from
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb
>> .  I can download and build the driver (kinda of messy), but I haven't
>> tested it yet.  You can see the progress on my Github.
>>
>> I've automated the license acceptance as well as the sgx driver build.
>>  Still working on the rest.
>>
>> Spenser
>>
>> On Wed, May 22, 2013 at 9:04 AM, Thomas Petazzoni
>> <[hidden email]> wrote:
>>
>>
>>> Dear prabindh,
>>>
>>> On Wed, 22 May 2013 06:35:55 -0700 (PDT), prabindh wrote:
>>>
>>>> Yes, I am talking about rebuilding the userspace libraries. I deliver
>>>> the Graphics drivers for SGX.
>>>
>>> Ah, nice to have you on board then :-) We may certainly have questions
>>> as we integrate those libraries in Buildroot.
>>>
>>>> The aspect of uclibc breaking compatibility was not clear to me
>>>> earlier. How do you plan to support "any" closed source packages
>>>> then ?
>>>
>>> With (e)glibc libraries, that we support through the external toolchain
>>> mechanism.
>>>
>>>> Why cant we have backward compatibility in uclibc ?
>>>
>>> I am not sure how accurate
>>>
>>> https://www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt
>>> is, must it says:
>>>
>>> """
>>> 3) uClibc does not even attempt to ensure binary compatibility across
>>> releases. When a new version of uClibc is released, you may or may not
>>> need to recompile all your binaries.
>>> """
>>>
>>> That said, the uClibc web site, at http://www.uclibc.org/oldnews.html,
>>> says:
>>>
>>> """
>>> Please be aware we will break binary compatibilty in the upcoming
>>> 0.9.27 release to implement a few necessary changes we have been
>>> postponing. That will hopefully be the last ABI change before we freeze
>>> the ABI for the upcoming 1.0.x stable uClibc series.
>>> """
>>>
>>> So it looks like there was some intention about having a stable ABI at
>>> some point. But this news was from 2004, and the 1.0.x stable uClibc
>>> series still hasn't been released, 9 years later.
>>>
>>> Maybe other people can comment? Or maybe we should bring the issue to
>>> the uClibc developers and see what they say?
>>>
>>> In the mean time, my expectation is that we will be using all those
>>> binary-only libraries on top of glibc/eglibc only. If you're doing some
>>> crazy OpenGL multimedia stuff, you can anyway afford the comparatively
>>> small additional cost of using glibc/eglibc in your embedded Linux
>>> system.
>>>
>>> Best regards,
>>>
>>> Thomas
>>> --
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>>> _______________________________________________
>>> buildroot mailing list
>>> [hidden email]
>>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
>>
>>
>>
>> --
>> Spenser Gilliland
>> Computer Engineer
>> Doctoral Candidate
>> _______________________________________________
>> buildroot mailing list
>> [hidden email]
>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
>> ________________________________
>>
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45674.html
>>
>> To unsubscribe from Currently packaging Qt5, click here.
>> NAML
>>
>>
>> ________________________________
>> View this message in context: RE: Currently packaging Qt5
>> Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
>
> --
> Spenser Gilliland
> Computer Engineer
> Doctoral Candidate
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear prabindh,

On Sun, 19 May 2013 20:31:35 -0700 (PDT), prabindh wrote:

> Using default cross-compiled toolchain for the Beaglebone, some of the Xorg
> libraries are failing to link, with below errors:
> 
> undefined reference to `pwrite64'
> undefined reference to `pread64'

Have you enable largefile support in your configuration?

> I need C++ toolchain as well, that does not seem to be built with buildroot
> by default. Are the below the right set of options to add to have this
> support ?
> 
> "BR2_GCC_CROSS_CXX=y BR2_INSTALL_LIBSTDCPP=y"

The first one is useless, because it enables C++ on the native compiler
on the target (which is a deprecated feature anyway). And also, this
BR2_GCC_CROSS_CXX option has been removed in december 2010. I would
_really_ recommend you to upgrade to a more recent Buildroot version.
We're clearly not going to support a Buildroot version that's 2 years
old, considering how many things have changed since then.

BR2_INSTALL_LIBSTDCPP (despite its bizarre name) is the right option to
have C++ support in the cross-compiler.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[prabindh]

Hello Thomas,

Will check the below.

>> Have you enable largefile support in your configuration?

I am using "buildroot-2013.02",  the below was copied from another post that I found the same topic.

>> BR2_GCC_CROSS_CXX option has been removed in december 2010. I would 
_really_ recommend you to upgrade to a more recent Buildroot version. 


regards,
Prabindh

From: Thomas Petazzoni-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45655h8 at n4.nabble.com] 
Sent: Wednesday, May 22, 2013 5:47 PM
To: Sundareson, Prabindh
Subject: Re: Currently packaging Qt5

Dear prabindh, 

On Sun, 19 May 2013 20:31:35 -0700 (PDT), prabindh wrote: 

> Using default cross-compiled toolchain for the Beaglebone, some of the Xorg 
> libraries are failing to link, with below errors: 
> 
> undefined reference to `pwrite64' 
> undefined reference to `pread64' 

Have you enable largefile support in your configuration? 

> I need C++ toolchain as well, that does not seem to be built with buildroot 
> by default. Are the below the right set of options to add to have this 
> support ? 
> 
> "BR2_GCC_CROSS_CXX=y BR2_INSTALL_LIBSTDCPP=y" 

The first one is useless, because it enables C++ on the native compiler 
on the target (which is a deprecated feature anyway). And also, this 
BR2_GCC_CROSS_CXX option has been removed in december 2010. I would 
_really_ recommend you to upgrade to a more recent Buildroot version. 
We're clearly not going to support a Buildroot version that's 2 years 
old, considering how many things have changed since then. 

BR2_INSTALL_LIBSTDCPP (despite its bizarre name) is the right option to 
have C++ support in the cross-compiler. 

Thomas 
-- 
Thomas Petazzoni, Free Electrons 
Kernel, drivers, real-time and embedded Linux 
development, consulting, training and support. 
http://free-electrons.com
_______________________________________________ 
buildroot mailing list 
[hidden email] 
http://lists.busybox.net/mailman/listinfo/buildroot

________________________________________
If you reply to this email, your message will be added to the discussion below:
http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45655.html 
To unsubscribe from Currently packaging Qt5, click here.
NAML 




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Currently-packaging-Qt5-tp38584p45658.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130522/17248b7a/attachment.html>

[Buildroot] Currently packaging Qt5

[Luca Ceresoli]

Thomas Petazzoni wrote:
> Hello,
>
> This is just a quick note to let people know that I've started
> packaging Qt5. I'm re-using existing packaging efforts done by
> RasberryPi folks, and I'm already quite far in the process. I hope to
> be able to post something soon.

Great!

Are you going to leave the option in BR to use the old QT4?
I think it would be useful, mostly for boards having no OGLES
acceleration, as well as to avoid any backward compatibility issues
for old application code.

Luca

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Luca,

On Mon, 14 Jan 2013 12:37:28 +0100, Luca Ceresoli wrote:

> Are you going to leave the option in BR to use the old QT4?

Yes, I packaging Qt5 as a completely separate package from Qt4.

In fact, I'm even packaging it as multiple separate packages, because
they now provide split tarballs for various components of the Qt5
stack, which is great.

> I think it would be useful, mostly for boards having no OGLES
> acceleration, as well as to avoid any backward compatibility issues
> for old application code.

Of course. Note however that Qt5 doesn't require OpenGLES. There are
linuxfb and directfb backend that normally work with OpenGLES.

However, the linuxfb backend is crashing at the moment. I've already
sent one (easy) fix to the Qt guys, and reported the next crash.
They suggested some thing that didn't work, I'm still waiting for some
news.

So basically, the stuff will compile, I can build and run a basic QtCore
application, but there will be some work to runtime test all the
combinations of graphical backends and so on. I will not be testing
everything.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Sagaert Johan]

 
Just a hint : 

https://github.com/nezticle/RaspberryPi-BuildRoot has the QT5 integrated
with the squask toolchain in buildroot.
Maintained by Andy Nichols [nezticle at gmail.com]

Regards, Johan


-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
Verzonden: maandag 14 januari 2013 12:45
Aan: Luca Ceresoli
CC: buildroot at busybox.net
Onderwerp: Re: [Buildroot] Currently packaging Qt5

Luca,

On Mon, 14 Jan 2013 12:37:28 +0100, Luca Ceresoli wrote:

> Are you going to leave the option in BR to use the old QT4?

Yes, I packaging Qt5 as a completely separate package from Qt4.

In fact, I'm even packaging it as multiple separate packages, because they now provide split tarballs for various components of the
Qt5 stack, which is great.

> I think it would be useful, mostly for boards having no OGLES 
> acceleration, as well as to avoid any backward compatibility issues 
> for old application code.

Of course. Note however that Qt5 doesn't require OpenGLES. There are linuxfb and directfb backend that normally work with OpenGLES.

However, the linuxfb backend is crashing at the moment. I've already sent one (easy) fix to the Qt guys, and reported the next
crash.
They suggested some thing that didn't work, I'm still waiting for some news.

So basically, the stuff will compile, I can build and run a basic QtCore application, but there will be some work to runtime test
all the combinations of graphical backends and so on. I will not be testing everything.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Sagaert Johan,

On Mon, 14 Jan 2013 13:48:12 +0100, Sagaert Johan wrote:

> Just a hint : 
> 
> https://github.com/nezticle/RaspberryPi-BuildRoot has the QT5 integrated
> with the squask toolchain in buildroot.
> Maintained by Andy Nichols [nezticle at gmail.com]

Yes, that's what I'm using as an inspiration, even though I'm making
things a bit more configurable (provide more options for graphical
backends, etc.).

I'm still wondering why so many people are doing Buildroot forks
without contributing back the valuable work they are doing.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Arnout Vandecappelle]

On 14/01/13 14:10, Thomas Petazzoni wrote:
> Dear Sagaert Johan,
>
> On Mon, 14 Jan 2013 13:48:12 +0100, Sagaert Johan wrote:
>
>> Just a hint :
>>
>> https://github.com/nezticle/RaspberryPi-BuildRoot has the QT5 integrated
>> with the squask toolchain in buildroot.
>> Maintained by Andy Nichols [nezticle at gmail.com]
>
> Yes, that's what I'm using as an inspiration, even though I'm making
> things a bit more configurable (provide more options for graphical
> backends, etc.).
>
> I'm still wondering why so many people are doing Buildroot forks
> without contributing back the valuable work they are doing.

  Maybe we should schedule some effort to discuss that on these projects' 
mailing lists.

  It seems BTW that those projects are typically also forking, without 
merging updates in buildroot itself. Shame.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Currently packaging Qt5

[Daniel Nyström]

On Mon, Jan 14, 2013 at 10:58 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> This is just a quick note to let people know that I've started
> packaging Qt5. I'm re-using existing packaging efforts done by
> RasberryPi folks, and I'm already quite far in the process. I hope to
> be able to post something soon.
>

Hi Thomas! Do you think there are any chance Qt5 will make it to 2013.02?

Best regards
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130206/ca8693a3/attachment-0001.html>

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Daniel Nystr?m,

On Wed, 6 Feb 2013 10:56:32 +0100, Daniel Nystr?m wrote:

> Hi Thomas! Do you think there are any chance Qt5 will make it to 2013.02?

Unfortunately no, the packages are not completely ready. I still have
linking issues due to incorrect library paths.

You can follow my work at
http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=qt5
if you're interested.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Currently packaging Qt5

[Frédéric COIFFIER]

Hello Thomas,

Did you get a patch for solving your segfault with the LinuxFb backend ?
I made a similar test few weeks ago and got the same problem on an i.MX6
board.
I saw your mail in the Qt-project mailing list but no answer from the Qt
team

Regards,
Frederic

On 02/06/2013 11:04 AM, Thomas Petazzoni wrote:
> Unfortunately no, the packages are not completely ready. I still have
> linking issues due to incorrect library paths.
>
> You can follow my work at
> http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=qt5
> if you're interested.
>
> Best regards,
>
> Thomas


//

[Buildroot] Currently packaging Qt5

[Thomas Petazzoni]

Dear Fr?d?ric COIFFIER,

On Wed, 06 Feb 2013 11:12:21 +0100, Fr?d?ric COIFFIER wrote:

> Did you get a patch for solving your segfault with the LinuxFb backend ?
> I made a similar test few weeks ago and got the same problem on an i.MX6
> board.
> I saw your mail in the Qt-project mailing list but no answer from the Qt
> team

Yes, there were two problems:

 * An ioctl() related problem, which I fixed (patch had been sent on
   the qt-interest mailing list)

 * A crash after that. But I was told a few days ago that the crash
   only appeared with the specific example application I was trying,
   and that all the other applications worked fine. Since I got this
   information, I haven't been able to test it by myself. I'll do so as
   soon as I start working on Qt5 again, hopefully this week.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com