Thank you for the fast answers!
Enabling the extensions ( - -std=gnu++11) has fixed the issue for me.
Anyhow, I noticed that I still cannot use the set_config_tunable() to
set the mem_pool_size. I configure it as described below, but I still
get the warning
WARNING: [APP] heapobj_init() failed for xxx bytes, raise --mem-pool-size?
If I use the command line option --mem-pool-size it works without any
issues, but I´d like to include it in the code.
Also, as secondary issue, I cannot use the syntax of 1G to define the
size, as G is not defined (error below). That´s why I have the "GBYTE"
definition.
error: unable to find numeric literal operator ‘operator"" G’
#define GBYTE (1024*1024*1024)
static int my_tune(void){
set_config_tunable(mem_pool_size, 1*GBYTE);
printf("mem pool size=%ld\n",get_config_tunable(mem_pool_size));
return 0;
}
static struct setup_descriptor my_setup = {
.name = "mySetup",
.tune = my_tune,
};
user_setup_call(my_setup);
Any ideas on these points?
Thank you in advance and regards,
Cristina.
El mié., 10 jul. 2019 23:43, Jan Kiszka <[email protected]> escribió:
>
> On 10.07.19 22:50, Philippe Gerum wrote:
> > On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
> >> From: Jan Kiszka <[email protected]>
> >>
> >> This was ignored by most compilers so far, but it breaks at least under
> >> c++11.
> >
> > This was hardly ignored since this evaluates to a required type
> > information, the issue is rather with typeof() belonging to the GNU
> > extension set. Building with -std=gnu++11 solves that issue with the
> > current implementation which generally assumes those extensions are enabled.
>
> If these two cases are the only ones that prevent standard-conforming builds
> ouf
> our external headers, I would be in favor of overcoming that limitation. But
> if
> it should be just the tip of the iceberg, it's likely not worth it.
>
> >
> >>
> >> Reported-by: Stéphane Ancelot <[email protected]>
> >> Reported-by: Cris Almaraz <[email protected]>
> >> Signed-off-by: Jan Kiszka <[email protected]>
> >> ---
> >>
> >> Thanks for reporting (and sorry for the long patch delay). This should
> >> fix it.
> >>
> >> include/boilerplate/tunables.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/boilerplate/tunables.h
> >> b/include/boilerplate/tunables.h
> >> index db8523be67..38f414e455 100644
> >> --- a/include/boilerplate/tunables.h
> >> +++ b/include/boilerplate/tunables.h
> >> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
> >> __read_ ## __name ## _ ## __scope
> >>
> >> #define __define_tunable(__name, __type, __val, __scope) \
> >> - void __tunable_set_call(__name, __scope)(typeof(__type) __val)
> >> + void __tunable_set_call(__name, __scope)(__type __val)
> >>
> >> #define __read_tunable(__name, __type, __scope) \
> >> - typeof(__type) __tunable_get_call(__name, __scope)(void)
> >> + __type __tunable_get_call(__name, __scope)(void)
> >>
> >> #define define_config_tunable(__name, __type, __val) \
> >> __define_tunable(__name, __type, __val, config)
> >> --
> >
> >
> > That won't work with non-trivial type expr like this one:
> >
> > int (*foo_handler)(void);
> >
> > define_config_tunable(foobar, int (*)(void), handler)
> > {
> > foo_handler = handler;
> > }
> >
> > And we have those in the field already.
> >
>
> Out of tree? I didn't find any in-tree build issues.
>
> Jan
