* [Xenomai] Importance of missing modechk/cobolt.wrappers @ 2018-08-29 15:15 Per Oberg 2018-08-29 16:01 ` Philippe Gerum 0 siblings, 1 reply; 5+ messages in thread From: Per Oberg @ 2018-08-29 15:15 UTC (permalink / raw) To: xenomai Hello all I'm working with a Yocto build of xenomai. I have compiled a sdk for building on a build-host but I am doing something wrong because I get the wrong path to modechk.wrappers and cobalt.wrappers. I could probably fix this but I just want to know whether this is a real problem or not. When I run xeno-config i get : Xenomai: wrappers cannot be read from /usr/lib/modechk.wrappers Xenomai: wrappers cannot be read from /usr/lib/cobalt.wrappers The contents of the wrapper files are listed below for completeness. It seems like a lot of stuff that is not getting wrapped when these files are missing, and that would mean that I am missing a lot of wrapping and that I definitely need to fix it. Or is is just a warning? How do I know if the final software is wrapping stuff the way I want? ---------------------------------------------------------------- modechk.wrappers : ---------------------------------------------------------------- --wrap malloc --wrap free and ---------------------------------------------------------------- cobalt.wrappers : ---------------------------------------------------------------- --wrap pthread_attr_init --wrap pthread_create --wrap pthread_setschedparam --wrap pthread_getschedparam --wrap pthread_yield --wrap sched_yield --wrap sched_get_priority_min --wrap sched_get_priority_max --wrap sched_setscheduler --wrap sched_getscheduler --wrap pthread_kill --wrap pthread_join --wrap pthread_setname_np --wrap sem_init --wrap sem_destroy --wrap sem_post --wrap sem_timedwait --wrap sem_wait --wrap sem_trywait --wrap sem_getvalue --wrap sem_open --wrap sem_close --wrap sem_unlink --wrap clock_getres --wrap clock_gettime --wrap clock_settime --wrap clock_nanosleep --wrap nanosleep --wrap pthread_mutex_init --wrap pthread_mutex_destroy --wrap pthread_mutex_lock --wrap pthread_mutex_trylock --wrap pthread_mutex_timedlock --wrap pthread_mutex_unlock --wrap pthread_cond_init --wrap pthread_cond_destroy --wrap pthread_cond_wait --wrap pthread_cond_timedwait --wrap pthread_cond_signal --wrap pthread_cond_broadcast --wrap mq_open --wrap mq_close --wrap mq_unlink --wrap mq_getattr --wrap mq_setattr --wrap mq_send --wrap mq_timedsend --wrap mq_receive --wrap mq_timedreceive --wrap mq_notify --wrap open --wrap open64 --wrap socket --wrap close --wrap ioctl --wrap read --wrap write --wrap recvmsg --wrap sendmsg --wrap recvfrom --wrap sendto --wrap recv --wrap send --wrap getsockopt --wrap setsockopt --wrap bind --wrap connect --wrap listen --wrap accept --wrap getsockname --wrap getpeername --wrap shutdown --wrap timer_create --wrap timer_delete --wrap timer_settime --wrap timer_getoverrun --wrap timer_gettime --wrap timerfd_create --wrap timerfd_gettime --wrap timerfd_settime --wrap select --wrap vfprintf --wrap vprintf --wrap fprintf --wrap printf --wrap puts --wrap fputs --wrap fputc --wrap putchar --wrap fwrite --wrap fclose --wrap syslog --wrap vsyslog --wrap gettimeofday --wrap __vfprintf_chk --wrap __vprintf_chk --wrap __fprintf_chk --wrap __printf_chk --wrap __vsyslog_chk --wrap __syslog_chk --wrap sigwait --wrap sigwaitinfo --wrap sigtimedwait --wrap sigpending --wrap sigqueue --wrap kill --wrap sleep --wrap mmap --wrap mmap64 --wrap time --wrap fcntl Regards Per Öberg ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Importance of missing modechk/cobolt.wrappers 2018-08-29 15:15 [Xenomai] Importance of missing modechk/cobolt.wrappers Per Oberg @ 2018-08-29 16:01 ` Philippe Gerum 2018-08-30 7:17 ` Per Oberg 0 siblings, 1 reply; 5+ messages in thread From: Philippe Gerum @ 2018-08-29 16:01 UTC (permalink / raw) To: Per Oberg, xenomai On 08/29/2018 05:15 PM, Per Oberg wrote: > Hello all > > > I'm working with a Yocto build of xenomai. I have compiled a sdk for building on a build-host but I am doing something wrong because I get the wrong path to modechk.wrappers and cobalt.wrappers. I could probably fix this but I just want to know whether this is a real problem or not. > > When I run xeno-config i get : > Xenomai: wrappers cannot be read from /usr/lib/modechk.wrappers > Xenomai: wrappers cannot be read from /usr/lib/cobalt.wrappers > > The contents of the wrapper files are listed below for completeness. It seems like a lot of stuff that is not getting wrapped when these files are missing, and that would mean that I am missing a lot of wrapping and that I definitely need to fix it. Or is is just a warning? > It's an important warning, your build may be broken. This means that wrapping failed for any executable depending on it, which retrieved its linker flags from xeno-config --ldflags. Basically, all built-in Xenomai apps (e.g. latency, switchtest), and any user application depending on xeno-config for retrieving those flags. > How do I know if the final software is wrapping stuff the way I want? Dumping the executable's namelist should always refer to the wrapper for any routine listed in the wrapper files. e.g. $ nm -u $executable | grep 'U __wrap_' U __wrap_clock_gettime U __wrap_close U __wrap_fclose U __wrap_fprintf U __wrap_fputc U __wrap_fputs U __wrap_free U __wrap_fwrite U __wrap_ioctl U __wrap_kill U __wrap_malloc U __wrap_open U __wrap_printf U __wrap_pthread_attr_init U __wrap_pthread_create U __wrap_pthread_join U __wrap_pthread_setname_np U __wrap_puts U __wrap_read U __wrap_sem_close U __wrap_sem_open U __wrap_sem_post U __wrap_sem_unlink U __wrap_sem_wait U __wrap_time U __wrap_timerfd_create U __wrap_timerfd_settime U __wrap_write -- Philippe. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Importance of missing modechk/cobolt.wrappers 2018-08-29 16:01 ` Philippe Gerum @ 2018-08-30 7:17 ` Per Oberg 2018-08-30 7:41 ` Per Oberg 2018-08-31 10:19 ` Philippe Gerum 0 siblings, 2 replies; 5+ messages in thread From: Per Oberg @ 2018-08-30 7:17 UTC (permalink / raw) To: xenomai ----- Den 29 aug 2018, på kl 18:01, Philippe Gerum rpm@xenomai.org skrev: > On 08/29/2018 05:15 PM, Per Oberg wrote: > > Hello all >> I'm working with a Yocto build of xenomai. I have compiled a sdk for building on >> a build-host but I am doing something wrong because I get the wrong path to >> modechk.wrappers and cobalt.wrappers. I could probably fix this but I just want > > to know whether this is a real problem or not. > > When I run xeno-config i get : > > Xenomai: wrappers cannot be read from /usr/lib/modechk.wrappers > > Xenomai: wrappers cannot be read from /usr/lib/cobalt.wrappers >> The contents of the wrapper files are listed below for completeness. It seems >> like a lot of stuff that is not getting wrapped when these files are missing, >> and that would mean that I am missing a lot of wrapping and that I definitely > > need to fix it. Or is is just a warning? > It's an important warning, your build may be broken. This means that > wrapping failed for any executable depending on it, which retrieved its > linker flags from xeno-config --ldflags. Basically, all built-in Xenomai > apps (e.g. latency, switchtest), and any user application depending on > xeno-config for retrieving those flags. > > How do I know if the final software is wrapping stuff the way I want? > Dumping the executable's namelist should always refer to the wrapper for > any routine listed in the wrapper files. e.g. > $ nm -u $executable | grep 'U __wrap_' > U __wrap_clock_gettime > U __wrap_close > U __wrap_fclose > U __wrap_fprintf > U __wrap_fputc > U __wrap_fputs > U __wrap_free > U __wrap_fwrite > U __wrap_ioctl > U __wrap_kill > U __wrap_malloc > U __wrap_open > U __wrap_printf > U __wrap_pthread_attr_init > U __wrap_pthread_create > U __wrap_pthread_join > U __wrap_pthread_setname_np > U __wrap_puts > U __wrap_read > U __wrap_sem_close > U __wrap_sem_open > U __wrap_sem_post > U __wrap_sem_unlink > U __wrap_sem_wait > U __wrap_time > U __wrap_timerfd_create > U __wrap_timerfd_settime > U __wrap_write > -- > Philippe. Thanks for that, I suspected this was the case. I did do some checking on the built-in Xenomai apps and they are compiled using the right flags. This does not puzzle me because we are usually able to trust the magic of the build system for solving this. (Meaning: Since there are no libraries, linker files, or other dependencies in the "prefix" directories during the first build the tools must all be referring to the build-dir instead of the prefix destination.) In my case, since I'm building for a target with no build tools installed (which I assume would be quite normal for a lot of people doing real time stuff) I need to prepare some kind of SDK. For the X86 platform I can install Xenomai on my laptop, and have the exact same setup on the target. But I rather not have it this way. Is there some kind of special flag I can use during build of the SDK or how do people generally go about this? Perhaps this is more of a Yocto-question or question of build-systems in general but I guess Xenomai-users should be quite good at setting these things up. Thanks Per Öberg ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Importance of missing modechk/cobolt.wrappers 2018-08-30 7:17 ` Per Oberg @ 2018-08-30 7:41 ` Per Oberg 2018-08-31 10:19 ` Philippe Gerum 1 sibling, 0 replies; 5+ messages in thread From: Per Oberg @ 2018-08-30 7:41 UTC (permalink / raw) To: xenomai Please visit us at: [ http://www.wolframmathcore.com/ | wolframmathcore.com ] or [ http://www.wolfram.com/ | wolfram.com ] ----- Den 30 aug 2018, på kl 9:17, Per Öberg pero@wolfram.com skrev: > ----- Den 29 aug 2018, på kl 18:01, Philippe Gerum rpm@xenomai.org skrev: > > On 08/29/2018 05:15 PM, Per Oberg wrote: > > > Hello all > >> I'm working with a Yocto build of xenomai. I have compiled a sdk for building on > >> a build-host but I am doing something wrong because I get the wrong path to > >> modechk.wrappers and cobalt.wrappers. I could probably fix this but I just want > > > to know whether this is a real problem or not. > > > When I run xeno-config i get : > > > Xenomai: wrappers cannot be read from /usr/lib/modechk.wrappers > > > Xenomai: wrappers cannot be read from /usr/lib/cobalt.wrappers > >> The contents of the wrapper files are listed below for completeness. It seems > >> like a lot of stuff that is not getting wrapped when these files are missing, > >> and that would mean that I am missing a lot of wrapping and that I definitely > > > need to fix it. Or is is just a warning? > > It's an important warning, your build may be broken. This means that > > wrapping failed for any executable depending on it, which retrieved its > > linker flags from xeno-config --ldflags. Basically, all built-in Xenomai > > apps (e.g. latency, switchtest), and any user application depending on > > xeno-config for retrieving those flags. > > > How do I know if the final software is wrapping stuff the way I want? > > Dumping the executable's namelist should always refer to the wrapper for > > any routine listed in the wrapper files. e.g. > > $ nm -u $executable | grep 'U __wrap_' > > U __wrap_clock_gettime > > U __wrap_close > > U __wrap_fclose > > U __wrap_fprintf > > U __wrap_fputc > > U __wrap_fputs > > U __wrap_free > > U __wrap_fwrite > > U __wrap_ioctl > > U __wrap_kill > > U __wrap_malloc > > U __wrap_open > > U __wrap_printf > > U __wrap_pthread_attr_init > > U __wrap_pthread_create > > U __wrap_pthread_join > > U __wrap_pthread_setname_np > > U __wrap_puts > > U __wrap_read > > U __wrap_sem_close > > U __wrap_sem_open > > U __wrap_sem_post > > U __wrap_sem_unlink > > U __wrap_sem_wait > > U __wrap_time > > U __wrap_timerfd_create > > U __wrap_timerfd_settime > > U __wrap_write > > -- > > Philippe. > Thanks for that, I suspected this was the case. > I did do some checking on the built-in Xenomai apps and they are compiled using > the right flags. This does not puzzle me because we are usually able to trust > the magic of the build system for solving this. (Meaning: Since there are no > libraries, linker files, or other dependencies in the "prefix" directories > during the first build the tools must all be referring to the build-dir instead > of the prefix destination.) > In my case, since I'm building for a target with no build tools installed (which > I assume would be quite normal for a lot of people doing real time stuff) I > need to prepare some kind of SDK. For the X86 platform I can install Xenomai on > my laptop, and have the exact same setup on the target. But I rather not have > it this way. Is there some kind of special flag I can use during build of the > SDK or how do people generally go about this? I just found the DESTDIR environment variable, it was quite easily found in the documentation. > Perhaps this is more of a Yocto-question or question of build-systems in general > but I guess Xenomai-users should be quite good at setting these things up. > Thanks > Per Öberg Thanks Per Öberg ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai] Importance of missing modechk/cobolt.wrappers 2018-08-30 7:17 ` Per Oberg 2018-08-30 7:41 ` Per Oberg @ 2018-08-31 10:19 ` Philippe Gerum 1 sibling, 0 replies; 5+ messages in thread From: Philippe Gerum @ 2018-08-31 10:19 UTC (permalink / raw) To: Per Oberg, xenomai On 08/30/2018 09:17 AM, Per Oberg wrote: > > ----- Den 29 aug 2018, på kl 18:01, Philippe Gerum rpm@xenomai.org skrev: > >> On 08/29/2018 05:15 PM, Per Oberg wrote: >>> Hello all > > >>> I'm working with a Yocto build of xenomai. I have compiled a sdk for building on >>> a build-host but I am doing something wrong because I get the wrong path to >>> modechk.wrappers and cobalt.wrappers. I could probably fix this but I just want >>> to know whether this is a real problem or not. > >>> When I run xeno-config i get : >>> Xenomai: wrappers cannot be read from /usr/lib/modechk.wrappers >>> Xenomai: wrappers cannot be read from /usr/lib/cobalt.wrappers > >>> The contents of the wrapper files are listed below for completeness. It seems >>> like a lot of stuff that is not getting wrapped when these files are missing, >>> and that would mean that I am missing a lot of wrapping and that I definitely >>> need to fix it. Or is is just a warning? > > >> It's an important warning, your build may be broken. This means that >> wrapping failed for any executable depending on it, which retrieved its >> linker flags from xeno-config --ldflags. Basically, all built-in Xenomai >> apps (e.g. latency, switchtest), and any user application depending on >> xeno-config for retrieving those flags. > >>> How do I know if the final software is wrapping stuff the way I want? > >> Dumping the executable's namelist should always refer to the wrapper for >> any routine listed in the wrapper files. e.g. > >> $ nm -u $executable | grep 'U __wrap_' > >> U __wrap_clock_gettime >> U __wrap_close >> U __wrap_fclose >> U __wrap_fprintf >> U __wrap_fputc >> U __wrap_fputs >> U __wrap_free >> U __wrap_fwrite >> U __wrap_ioctl >> U __wrap_kill >> U __wrap_malloc >> U __wrap_open >> U __wrap_printf >> U __wrap_pthread_attr_init >> U __wrap_pthread_create >> U __wrap_pthread_join >> U __wrap_pthread_setname_np >> U __wrap_puts >> U __wrap_read >> U __wrap_sem_close >> U __wrap_sem_open >> U __wrap_sem_post >> U __wrap_sem_unlink >> U __wrap_sem_wait >> U __wrap_time >> U __wrap_timerfd_create >> U __wrap_timerfd_settime >> U __wrap_write > >> -- >> Philippe. > > Thanks for that, I suspected this was the case. > > I did do some checking on the built-in Xenomai apps and they are compiled using the right flags. This does not puzzle me because we are usually able to trust the magic of the build system for solving this. Contradicting my original concern about this, the build rules for the built-in apps are picking the wrappers directly from the source tree, so this can't fail (which makes sense, as they should have been built before the installation process can take place anyway). (Meaning: Since there are no libraries, linker files, or other dependencies in the "prefix" directories during the first build the tools must all be referring to the build-dir instead of the prefix destination.) > > In my case, since I'm building for a target with no build tools installed (which I assume would be quite normal for a lot of people doing real time stuff) I need to prepare some kind of SDK. For the X86 platform I can install Xenomai on my laptop, and have the exact same setup on the target. But I rather not have it this way. Is there some kind of special flag I can use during build of the SDK or how do people generally go about this? > Are you referring to a staging dir? https://gitlab.denx.de/Xenomai/xenomai/wikis/Installing_Xenomai_3 discusses this I believe. -- Philippe. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-08-31 10:19 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-29 15:15 [Xenomai] Importance of missing modechk/cobolt.wrappers Per Oberg 2018-08-29 16:01 ` Philippe Gerum 2018-08-30 7:17 ` Per Oberg 2018-08-30 7:41 ` Per Oberg 2018-08-31 10:19 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.