| Message ID | 1373615072-5258-1-git-send-email-mjonker@synopsys.com |
|---|---|
| State | Superseded |
| Headers | show |
Dear Mischa Jonker, On Fri, 12 Jul 2013 09:44:32 +0200, Mischa Jonker wrote: > # No threading target is non-AIO as well > -ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),) > +ifeq ($(BR2_PTHREADS_NATIVE),) > IOZONE_TARGET = linux-noth > # AIO support not available on uClibc, use the linux (non-aio) target. > else ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y) BR2_PTHREADS_NATIVE is a Config.in option that only makes sense in the context of the internal toolchain backend. So any usage of it in package/ is going to not be suitable for external toolchain usage. So your change, as is, would disable thread support in IOZone for any external toolchain. Best regards, Thomas
Hi Thomas, > BR2_PTHREADS_NATIVE is a Config.in option that only makes sense in the > context of the internal toolchain backend. So any usage of it in package/ is > going to not be suitable for external toolchain usage. So your change, as is, > would disable thread support in IOZone for any external toolchain. Should we add a BR2_TOOLCHAIN_HAS_THREADS_NATIVE to toolchain/toolchain-common.in? Or do you have another suggestion? Mischa
Dear Mischa Jonker, On Fri, 12 Jul 2013 08:06:36 +0000, Mischa Jonker wrote: > > BR2_PTHREADS_NATIVE is a Config.in option that only makes sense in the > > context of the internal toolchain backend. So any usage of it in package/ is > > going to not be suitable for external toolchain usage. So your change, as is, > > would disable thread support in IOZone for any external toolchain. > > Should we add a BR2_TOOLCHAIN_HAS_THREADS_NATIVE to toolchain/toolchain-common.in? Or do you have another suggestion? Yes, I believe that's the only solution. In fact, it could also be used instead of the BR2_TOOLCHAIN_LIBC_NEEDS_THREE_STAGE_BUILD that's being added by my proposed patch "[PATCH] toolchain-internal: skip gcc-intermediate when possible". Best regards, Thomas
Thomas wrote: >> Should we add a BR2_TOOLCHAIN_HAS_THREADS_NATIVE to >> toolchain/toolchain- > common.in? Or do you have another suggestion? > > Yes, I believe that's the only solution. In fact, it could also be > used instead of the BR2_TOOLCHAIN_LIBC_NEEDS_THREE_STAGE_BUILD that's > being added by my proposed patch "[PATCH] toolchain-internal: skip > gcc-intermediate when possible". Do you think that it's a safe assumption that GLIBC toolchains have NPTL? (just like BR2_TOOLCHAIN_HAS_THREADS is selected already if BR2_TOOLCHAIN_USES_GLIBC). Mischa
diff --git a/package/iozone/iozone.mk b/package/iozone/iozone.mk index 328a526..c985141 100644 --- a/package/iozone/iozone.mk +++ b/package/iozone/iozone.mk @@ -12,7 +12,7 @@ IOZONE_LICENSE = IOzone license (NO DERIVED WORKS ALLOWED) # http://www.iozone.org/docs/Iozone_License.txt # No threading target is non-AIO as well -ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),) +ifeq ($(BR2_PTHREADS_NATIVE),) IOZONE_TARGET = linux-noth # AIO support not available on uClibc, use the linux (non-aio) target. else ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
iozone uses pthread_setaffinity_np, which is not supported in Linuxthreads. Signed-off-by: Mischa Jonker <mjonker@synopsys.com> --- package/iozone/iozone.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)