* [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains @ 2014-09-15 14:17 Matt Weber 2014-09-15 18:06 ` Thomas Petazzoni 0 siblings, 1 reply; 5+ messages in thread From: Matt Weber @ 2014-09-15 14:17 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains 2014-09-15 14:17 [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains Matt Weber @ 2014-09-15 18:06 ` Thomas Petazzoni 2014-09-15 18:30 ` Matthew Weber 0 siblings, 1 reply; 5+ messages in thread From: Thomas Petazzoni @ 2014-09-15 18:06 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains 2014-09-15 18:06 ` Thomas Petazzoni @ 2014-09-15 18:30 ` Matthew Weber 2014-09-16 1:07 ` Matthew Weber 0 siblings, 1 reply; 5+ messages in thread From: Matthew Weber @ 2014-09-15 18:30 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains 2014-09-15 18:30 ` Matthew Weber @ 2014-09-16 1:07 ` Matthew Weber 2014-09-16 6:34 ` Thomas Petazzoni 0 siblings, 1 reply; 5+ messages in thread From: Matthew Weber @ 2014-09-16 1:07 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains 2014-09-16 1:07 ` Matthew Weber @ 2014-09-16 6:34 ` Thomas Petazzoni 0 siblings, 0 replies; 5+ messages in thread From: Thomas Petazzoni @ 2014-09-16 6:34 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-09-16 6:34 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-15 14:17 [Buildroot] [PATCH 1/1] omniorb: limit to glibc toolchains Matt Weber 2014-09-15 18:06 ` Thomas Petazzoni 2014-09-15 18:30 ` Matthew Weber 2014-09-16 1:07 ` Matthew Weber 2014-09-16 6:34 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox