[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Matt Weber]

Resolves autobuilder failure where the omniorb package doesn't
correctly detect the OS because the configure script doesn't have
an option for uclinux support.  This results in a pthread create
assertion when it attempts to figure-out the correct C library
posix calls.

http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/

Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com>
---
 package/omniorb/Config.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/omniorb/Config.in b/package/omniorb/Config.in
index b8c4e0a..703cb64 100644
--- a/package/omniorb/Config.in
+++ b/package/omniorb/Config.in
@@ -1,9 +1,10 @@
 
-comment "omniORB needs a toolchain w/ C++, threads"
-	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
+comment "omniORB needs a glibc toolchain w/ C++, threads"
+	depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
 
 config BR2_PACKAGE_OMNIORB
 	bool "omniorb"
+	depends on BR2_TOOLCHAIN_USES_GLIBC
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	help
-- 
1.9.1

[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Thomas Petazzoni]

Dear Matt Weber,

On Mon, 15 Sep 2014 09:17:30 -0500, Matt Weber wrote:
> Resolves autobuilder failure where the omniorb package doesn't
> correctly detect the OS because the configure script doesn't have
> an option for uclinux support.  This results in a pthread create
> assertion when it attempts to figure-out the correct C library
> posix calls.
> 
> http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/
> 
> Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com>

Wait, wait, wait, no.

uclinux != uclibc.

uclinux is the part of the host tuple used only on noMMU platforms that
don't support shared libraries.

If you use uClibc on ARM, it's not a uClinux system.

So, clearly, disabling entirely the package for uClibc doesn't make
sense here.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Matthew Weber]

Thomas,

On Mon, Sep 15, 2014 at 1:06 PM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Dear Matt Weber,
>
> On Mon, 15 Sep 2014 09:17:30 -0500, Matt Weber wrote:
> > Resolves autobuilder failure where the omniorb package doesn't
> > correctly detect the OS because the configure script doesn't have
> > an option for uclinux support.  This results in a pthread create
> > assertion when it attempts to figure-out the correct C library
> > posix calls.
> >
> >
> http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/
> >
> > Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com>
>
> Wait, wait, wait, no.
>
> uclinux != uclibc.
>
> uclinux is the part of the host tuple used only on noMMU platforms that
> don't support shared libraries.
>
> If you use uClibc on ARM, it's not a uClinux system.
>
> So, clearly, disabling entirely the package for uClibc doesn't make
> sense here.
>

Thank you for that clarification, that makes a bit more sense on why this
issue didn't come up as often in the autobuilds.  I would assume that
updating this path to a needs MMU instead is the correct approach.



>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>



-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted Third
Party Intellectual Property (TPIP) content must be encrypted and sent to
matthew.weber at corp.rockwellcollins.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140915/b7aea58f/attachment.html>

[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Matthew Weber]

Dear Thomas,

On Mon, Sep 15, 2014 at 1:30 PM, Matthew Weber <
matthew.weber@rockwellcollins.com> wrote:

> Thomas,
>
> On Mon, Sep 15, 2014 at 1:06 PM, Thomas Petazzoni <
> thomas.petazzoni at free-electrons.com> wrote:
>
>> Dear Matt Weber,
>>
>> On Mon, 15 Sep 2014 09:17:30 -0500, Matt Weber wrote:
>> > Resolves autobuilder failure where the omniorb package doesn't
>> > correctly detect the OS because the configure script doesn't have
>> > an option for uclinux support.  This results in a pthread create
>> > assertion when it attempts to figure-out the correct C library
>> > posix calls.
>> >
>> >
>> http://autobuild.buildroot.net/results/fbe6c722b92fe4ddf7ac36a8fe1be3a3891c11fd/
>> >
>> > Signed-off-by: Matt Weber <Matthew.Weber@rockwellcollins.com>
>>
>> Wait, wait, wait, no.
>>
>> uclinux != uclibc.
>>
>> uclinux is the part of the host tuple used only on noMMU platforms that
>> don't support shared libraries.
>>
>> If you use uClibc on ARM, it's not a uClinux system.
>>
>> So, clearly, disabling entirely the package for uClibc doesn't make
>> sense here.
>>
>
> Thank you for that clarification, that makes a bit more sense on why this
> issue didn't come up as often in the autobuilds.  I would assume that
> updating this path to a needs MMU instead is the correct approach.
>

I retested with a "depends on BR2_USE_MMU", which excluded that package
from the bfin build.

I had another question.  Over the last couple weeks, I've created a couple
patches that can be discarded.  How do those get removed from patchworks?



>
>
>
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux, Kernel and Android engineering
>> http://free-electrons.com
>>
>
>
>
> --
> Matthew L Weber / Pr Software Engineer
> Airborne Information Systems / Security Systems and Software
> MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
> www.rockwellcollins.com
>
> Note: Any Export License Required Information and License Restricted Third
> Party Intellectual Property (TPIP) content must be encrypted and sent to
> matthew.weber at corp.rockwellcollins.com.
>



-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted Third
Party Intellectual Property (TPIP) content must be encrypted and sent to
matthew.weber at corp.rockwellcollins.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140915/fb661ef4/attachment.html>

[Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains

[Thomas Petazzoni]

Dear Matthew Weber,

On Mon, 15 Sep 2014 20:07:47 -0500, Matthew Weber wrote:

> > Thank you for that clarification, that makes a bit more sense on why this
> > issue didn't come up as often in the autobuilds.  I would assume that
> > updating this path to a needs MMU instead is the correct approach.
> 
> I retested with a "depends on BR2_USE_MMU", which excluded that package
> from the bfin build.

Did you test whether the package builds with Blackfin FDPIC ?

Looking at the build error, it doesn't seem to be MMU or noMMU related.

> I had another question.  Over the last couple weeks, I've created a couple
> patches that can be discarded.  How do those get removed from patchworks?

Either the patch submitter does it (everyone can create an account on
patchwork and then manage his own patches), or some patchwork
administrator does it (I think Peter, Yann, Thomas DS, me, and maybe a
few other core developers are patchwork admins).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com