Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On 11/24/23 23:28, Khem Raj wrote: On Fri, Nov 24, 2023 at 12:18 AM Martin Jansa wrote: On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin wrote: On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: The lzop is called in oe-core and I was under the impression that oe-core shouldn't depend on anything except bitbake . So either this stuff should be moved to meta-oe too (which would be unfortunate growth of dependencies) or the lzop should be reinstated . I would obviously be in favor of the later. There are plenty of recipes in oe-core that have optional features (enabled via PACKAGECONFIG) that depend on recipes that are not in core. If you enable them, bitbake will say that the needed recipe is missing and then you need to figure out which layer to add (typically something in meta-openembedded tree). This is not that different: optional feature, disabled by default, and the error will be the same: missing lzop recipe. I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses. do we have some data on how many machines are needing this ? if not then I think we can say that its not actively needed and few machines if any needing this can house the recipe in the BSP layer core support is still in core so that's good. At least if Marek agrees to maintain it instead of restoring Denys as maintainer :). That's good although it will be nicer to see a wider use case to keep it in core. I can think of at least two SoM vendors that actively use this. I don't think that's "a few machines if any". -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191221): https://lists.openembedded.org/g/openembedded-core/message/191221 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On Fri, Nov 24, 2023 at 12:18 AM Martin Jansa wrote: > > On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin > wrote: >> >> On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: >> >> > The lzop is called in oe-core and I was under the impression that >> > oe-core shouldn't depend on anything except bitbake . So either this >> > stuff should be moved to meta-oe too (which would be unfortunate growth >> > of dependencies) or the lzop should be reinstated . I would obviously be >> > in favor of the later. >> >> There are plenty of recipes in oe-core that have optional features >> (enabled via PACKAGECONFIG) that depend on recipes that are not in >> core. If you enable them, bitbake will say that the needed recipe is >> missing and then you need to figure out which layer to add (typically >> something in meta-openembedded tree). This is not that different: >> optional feature, disabled by default, and the error will be the same: >> missing lzop recipe. > > > I think this case is slightly different as this optional dependency might be > "enabled" by MACHINE config in some BSP layer and BSP layer depending on > meta-oe just to build the kernel (with BSP preferred compression) isn't great > - compared with some DISTRO config enabling some additional PACKAGECONFIG in > some other recipe the DISTRO uses. > do we have some data on how many machines are needing this ? if not then I think we can say that its not actively needed and few machines if any needing this can house the recipe in the BSP layer core support is still in core so that's good. > At least if Marek agrees to maintain it instead of restoring Denys as > maintainer :). That's good although it will be nicer to see a wider use case to keep it in core. > > Cheers, > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191217): https://lists.openembedded.org/g/openembedded-core/message/191217 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On 11/24/23 09:18, Martin Jansa wrote: On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin wrote: On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: The lzop is called in oe-core and I was under the impression that oe-core shouldn't depend on anything except bitbake . So either this stuff should be moved to meta-oe too (which would be unfortunate growth of dependencies) or the lzop should be reinstated . I would obviously be in favor of the later. There are plenty of recipes in oe-core that have optional features (enabled via PACKAGECONFIG) that depend on recipes that are not in core. If you enable them, bitbake will say that the needed recipe is missing and then you need to figure out which layer to add (typically something in meta-openembedded tree). This is not that different: optional feature, disabled by default, and the error will be the same: missing lzop recipe. I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses. At least if Marek agrees to maintain it instead of restoring Denys as maintainer :). The recipe seems low maintenance anyway and I use it often, so yeah, why not. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191181): https://lists.openembedded.org/g/openembedded-core/message/191181 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On 11/24/23 03:18, Martin Jansa wrote: On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin mailto:alex.kana...@gmail.com>> wrote: On Thu, 23 Nov 2023 at 22:07, Marek Vasut mailto:ma...@denx.de>> wrote: > The lzop is called in oe-core and I was under the impression that > oe-core shouldn't depend on anything except bitbake . So either this > stuff should be moved to meta-oe too (which would be unfortunate growth > of dependencies) or the lzop should be reinstated . I would obviously be > in favor of the later. There are plenty of recipes in oe-core that have optional features (enabled via PACKAGECONFIG) that depend on recipes that are not in core. If you enable them, bitbake will say that the needed recipe is missing and then you need to figure out which layer to add (typically something in meta-openembedded tree). This is not that different: optional feature, disabled by default, and the error will be the same: missing lzop recipe. I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses. It sounds like enabling the option forces the addition of another layer to an existing project. I understand the need for that if the PACKAGECONFIG added so additional package to the image, but in this case the option just needs an additional tool to create stuff needed for booting a board Philip At least if Marek agrees to maintain it instead of restoring Denys as maintainer :). Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191180): https://lists.openembedded.org/g/openembedded-core/message/191180 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/leave/8023207/21656/1426099254/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin wrote: > On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: > > > The lzop is called in oe-core and I was under the impression that > > oe-core shouldn't depend on anything except bitbake . So either this > > stuff should be moved to meta-oe too (which would be unfortunate growth > > of dependencies) or the lzop should be reinstated . I would obviously be > > in favor of the later. > > There are plenty of recipes in oe-core that have optional features > (enabled via PACKAGECONFIG) that depend on recipes that are not in > core. If you enable them, bitbake will say that the needed recipe is > missing and then you need to figure out which layer to add (typically > something in meta-openembedded tree). This is not that different: > optional feature, disabled by default, and the error will be the same: > missing lzop recipe. > I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses. At least if Marek agrees to maintain it instead of restoring Denys as maintainer :). Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191178): https://lists.openembedded.org/g/openembedded-core/message/191178 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: > The lzop is called in oe-core and I was under the impression that > oe-core shouldn't depend on anything except bitbake . So either this > stuff should be moved to meta-oe too (which would be unfortunate growth > of dependencies) or the lzop should be reinstated . I would obviously be > in favor of the later. There are plenty of recipes in oe-core that have optional features (enabled via PACKAGECONFIG) that depend on recipes that are not in core. If you enable them, bitbake will say that the needed recipe is missing and then you need to figure out which layer to add (typically something in meta-openembedded tree). This is not that different: optional feature, disabled by default, and the error will be the same: missing lzop recipe. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191177): https://lists.openembedded.org/g/openembedded-core/message/191177 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
On 11/23/23 09:26, Alexander Kanavin wrote: I'm not sure I agree. It's totally ok to depend on things that are not in core, if they're not enabled or tested on the AB by default, and what layer they're in is well known (meta-oe in this case). The lzop is called in oe-core and I was under the impression that oe-core shouldn't depend on anything except bitbake . So either this stuff should be moved to meta-oe too (which would be unfortunate growth of dependencies) or the lzop should be reinstated . I would obviously be in favor of the later. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191175): https://lists.openembedded.org/g/openembedded-core/message/191175 Mute This Topic: https://lists.openembedded.org/mt/102759947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
I'm not sure I agree. It's totally ok to depend on things that are not
in core, if they're not enabled or tested on the AB by default, and
what layer they're in is well known (meta-oe in this case).
Alex
On Thu, 23 Nov 2023 at 01:46, Marek Vasut wrote:
>
> This reverts commit dea5e8863792dc7bb3324b543e04da4c94a060aa.
>
> The original commit claims that lzop is unused in OE-core.
> That is not correct, the following places still use it and
> became unbuildable now:
> "
> meta/classes-recipe/image_types.bbclass:CONVERSION_CMD:lzo = "lzop -9
> ${IMAGE_NAME}.${type}"
> meta/classes-recipe/image_types.bbclass:CONVERSION_DEPENDS_lzo = "lzop-native"
> meta/classes-recipe/kernel-uboot.bbclass: lzop -9
> linux.bin
> meta/classes-recipe/kernel.bbclass:DEPENDS +=
> "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", "lzop-native", "", d)}"
> meta/classes-recipe/kernel.bbclass: lzop -df
> ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
> "
>
> Furthermore, LZO is the best compromise between kernel decompression
> time and size on low end ARM systems, that is why it is often used
> with e.g.:
> FIT_KERNEL_COMP_ALG = "lzo"
> FIT_KERNEL_COMP_ALG_EXTENSION = ".lzo"
>
> Reinstate the package to avoid breaking this use case.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Ross Burton
> Cc: Richard Purdie
> ---
> meta/conf/distro/include/maintainers.inc| 1 +
> meta/recipes-support/lzop/lzop/acinclude.m4 | 390
> meta/recipes-support/lzop/lzop_1.04.bb | 27 ++
> 3 files changed, 418 insertions(+)
> create mode 100644 meta/recipes-support/lzop/lzop/acinclude.m4
> create mode 100644 meta/recipes-support/lzop/lzop_1.04.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> index 35f8a72fa4..e95ab59d0d 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -484,6 +484,7 @@ RECIPE_MAINTAINER:pn-lua = "Alexander Kanavin
> "
> RECIPE_MAINTAINER:pn-lz4 = "Denys Dmytriyenko "
> RECIPE_MAINTAINER:pn-lzo = "Denys Dmytriyenko "
> RECIPE_MAINTAINER:pn-lzip = "Denys Dmytriyenko "
> +RECIPE_MAINTAINER:pn-lzop = "Denys Dmytriyenko "
> RECIPE_MAINTAINER:pn-m4 = "Robert Yang "
> RECIPE_MAINTAINER:pn-m4-native = "Robert Yang "
> RECIPE_MAINTAINER:pn-make = "Robert Yang "
> diff --git a/meta/recipes-support/lzop/lzop/acinclude.m4
> b/meta/recipes-support/lzop/lzop/acinclude.m4
> new file mode 100644
> index 00..0029c19c7d
> --- /dev/null
> +++ b/meta/recipes-support/lzop/lzop/acinclude.m4
> @@ -0,0 +1,390 @@
> +
> +AC_DEFUN([mfx_ACC_CHECK_ENDIAN], [
> +AC_C_BIGENDIAN([AC_DEFINE(ACC_ABI_BIG_ENDIAN,1,[Define to 1 if your machine
> is big endian.])],[AC_DEFINE(ACC_ABI_LITTLE_ENDIAN,1,[Define to 1 if your
> machine is little endian.])])
> +])#
> +
> +AC_DEFUN([mfx_ACC_CHECK_HEADERS], [
> +AC_HEADER_TIME
> +AC_CHECK_HEADERS([assert.h ctype.h dirent.h errno.h fcntl.h float.h limits.h
> malloc.h memory.h setjmp.h signal.h stdarg.h stddef.h stdint.h stdio.h
> stdlib.h string.h strings.h time.h unistd.h utime.h sys/stat.h sys/time.h
> sys/types.h sys/wait.h])
> +])#
> +
> +AC_DEFUN([mfx_ACC_CHECK_FUNCS], [
> +AC_CHECK_FUNCS(access alloca atexit atoi atol chmod chown ctime difftime
> fstat gettimeofday gmtime localtime longjmp lstat memcmp memcpy memmove
> memset mktime qsort raise setjmp signal snprintf strcasecmp strchr strdup
> strerror strftime stricmp strncasecmp strnicmp strrchr strstr time umask
> utime vsnprintf)
> +])#
> +
> +
> +AC_DEFUN([mfx_ACC_CHECK_SIZEOF], [
> +AC_CHECK_SIZEOF(short)
> +AC_CHECK_SIZEOF(int)
> +AC_CHECK_SIZEOF(long)
> +
> +AC_CHECK_SIZEOF(long long)
> +AC_CHECK_SIZEOF(__int16)
> +AC_CHECK_SIZEOF(__int32)
> +AC_CHECK_SIZEOF(__int64)
> +
> +AC_CHECK_SIZEOF(void *)
> +AC_CHECK_SIZEOF(size_t)
> +AC_CHECK_SIZEOF(ptrdiff_t)
> +])#
> +
> +
> +# /***
> +# // Check for ACC_conformance
> +# /
> +
> +AC_DEFUN([mfx_ACC_ACCCHK], [
> +mfx_tmp=$1
> +mfx_save_CPPFLAGS=$CPPFLAGS
> +dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic this
> here
> +test "X$mfx_tmp" = "X" || CPPFLAGS="$mfx_tmp $CPPFLAGS"
> +
> +AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
> +
> +AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> +[[#define ACC_CONFIG_NO_HEADER 1
> +#include "acc/acc.h"
> +#include "acc/acc_incd.h"
> +#undef ACCCHK_ASSERT
> +#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT_HEADER(expr)
> +#include "acc/acc_chk.ch"
> +#undef ACCCHK_ASSERT
> +static void test_acc_compile_time_assert(void) {
> +#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT(expr)
> +#include "acc/acc_chk.ch"
> +#undef ACCCHK_ASSERT
> +}
> +#undef NDEBUG
> +#include
> +static int test_acc_run_time_assert(int r) {
> +#define ACCCHK_ASSERT(expr) assert(expr);
> +#include "acc/a
[OE-core] [PATCH] Revert "lzop: remove recipe from oe-core"
This reverts commit dea5e8863792dc7bb3324b543e04da4c94a060aa.
The original commit claims that lzop is unused in OE-core.
That is not correct, the following places still use it and
became unbuildable now:
"
meta/classes-recipe/image_types.bbclass:CONVERSION_CMD:lzo = "lzop -9
${IMAGE_NAME}.${type}"
meta/classes-recipe/image_types.bbclass:CONVERSION_DEPENDS_lzo = "lzop-native"
meta/classes-recipe/kernel-uboot.bbclass: lzop -9
linux.bin
meta/classes-recipe/kernel.bbclass:DEPENDS +=
"${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", "lzop-native", "", d)}"
meta/classes-recipe/kernel.bbclass: lzop -df
${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
"
Furthermore, LZO is the best compromise between kernel decompression
time and size on low end ARM systems, that is why it is often used
with e.g.:
FIT_KERNEL_COMP_ALG = "lzo"
FIT_KERNEL_COMP_ALG_EXTENSION = ".lzo"
Reinstate the package to avoid breaking this use case.
Signed-off-by: Marek Vasut
---
Cc: Ross Burton
Cc: Richard Purdie
---
meta/conf/distro/include/maintainers.inc| 1 +
meta/recipes-support/lzop/lzop/acinclude.m4 | 390
meta/recipes-support/lzop/lzop_1.04.bb | 27 ++
3 files changed, 418 insertions(+)
create mode 100644 meta/recipes-support/lzop/lzop/acinclude.m4
create mode 100644 meta/recipes-support/lzop/lzop_1.04.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 35f8a72fa4..e95ab59d0d 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -484,6 +484,7 @@ RECIPE_MAINTAINER:pn-lua = "Alexander Kanavin
"
RECIPE_MAINTAINER:pn-lz4 = "Denys Dmytriyenko "
RECIPE_MAINTAINER:pn-lzo = "Denys Dmytriyenko "
RECIPE_MAINTAINER:pn-lzip = "Denys Dmytriyenko "
+RECIPE_MAINTAINER:pn-lzop = "Denys Dmytriyenko "
RECIPE_MAINTAINER:pn-m4 = "Robert Yang "
RECIPE_MAINTAINER:pn-m4-native = "Robert Yang "
RECIPE_MAINTAINER:pn-make = "Robert Yang "
diff --git a/meta/recipes-support/lzop/lzop/acinclude.m4
b/meta/recipes-support/lzop/lzop/acinclude.m4
new file mode 100644
index 00..0029c19c7d
--- /dev/null
+++ b/meta/recipes-support/lzop/lzop/acinclude.m4
@@ -0,0 +1,390 @@
+
+AC_DEFUN([mfx_ACC_CHECK_ENDIAN], [
+AC_C_BIGENDIAN([AC_DEFINE(ACC_ABI_BIG_ENDIAN,1,[Define to 1 if your machine is
big endian.])],[AC_DEFINE(ACC_ABI_LITTLE_ENDIAN,1,[Define to 1 if your machine
is little endian.])])
+])#
+
+AC_DEFUN([mfx_ACC_CHECK_HEADERS], [
+AC_HEADER_TIME
+AC_CHECK_HEADERS([assert.h ctype.h dirent.h errno.h fcntl.h float.h limits.h
malloc.h memory.h setjmp.h signal.h stdarg.h stddef.h stdint.h stdio.h stdlib.h
string.h strings.h time.h unistd.h utime.h sys/stat.h sys/time.h sys/types.h
sys/wait.h])
+])#
+
+AC_DEFUN([mfx_ACC_CHECK_FUNCS], [
+AC_CHECK_FUNCS(access alloca atexit atoi atol chmod chown ctime difftime fstat
gettimeofday gmtime localtime longjmp lstat memcmp memcpy memmove memset mktime
qsort raise setjmp signal snprintf strcasecmp strchr strdup strerror strftime
stricmp strncasecmp strnicmp strrchr strstr time umask utime vsnprintf)
+])#
+
+
+AC_DEFUN([mfx_ACC_CHECK_SIZEOF], [
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
+
+AC_CHECK_SIZEOF(long long)
+AC_CHECK_SIZEOF(__int16)
+AC_CHECK_SIZEOF(__int32)
+AC_CHECK_SIZEOF(__int64)
+
+AC_CHECK_SIZEOF(void *)
+AC_CHECK_SIZEOF(size_t)
+AC_CHECK_SIZEOF(ptrdiff_t)
+])#
+
+
+# /***
+# // Check for ACC_conformance
+# /
+
+AC_DEFUN([mfx_ACC_ACCCHK], [
+mfx_tmp=$1
+mfx_save_CPPFLAGS=$CPPFLAGS
+dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic this
here
+test "X$mfx_tmp" = "X" || CPPFLAGS="$mfx_tmp $CPPFLAGS"
+
+AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
+
+AC_LANG_CONFTEST([AC_LANG_PROGRAM(
+[[#define ACC_CONFIG_NO_HEADER 1
+#include "acc/acc.h"
+#include "acc/acc_incd.h"
+#undef ACCCHK_ASSERT
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT_HEADER(expr)
+#include "acc/acc_chk.ch"
+#undef ACCCHK_ASSERT
+static void test_acc_compile_time_assert(void) {
+#define ACCCHK_ASSERT(expr) ACC_COMPILE_TIME_ASSERT(expr)
+#include "acc/acc_chk.ch"
+#undef ACCCHK_ASSERT
+}
+#undef NDEBUG
+#include
+static int test_acc_run_time_assert(int r) {
+#define ACCCHK_ASSERT(expr) assert(expr);
+#include "acc/acc_chk.ch"
+#undef ACCCHK_ASSERT
+return r;
+}
+]], [[
+test_acc_compile_time_assert();
+if (test_acc_run_time_assert(1) != 1) return 1;
+]]
+)])
+
+mfx_tmp=FAILED
+_AC_COMPILE_IFELSE([], [mfx_tmp=yes])
+rm -f conftest.$ac_ext conftest.$ac_objext
+
+CPPFLAGS=$mfx_save_CPPFLAGS
+
+AC_MSG_RESULT([$mfx_tmp])
+case x$mfx_tmp in
+ xpassed | xyes) ;;
+ *)
+AC_MSG_NOTICE([])
+AC_MSG_NOTICE([Your compiler failed the ACC conformance test - for details
see ])
+AC_MSG_NOTICE([`config.log'. Please check
