> > Any static should be conditioned on CONFIG_LIB_SYSCALL for the > task_spawn() version in sched/task/task_spawn.c, however, that is not > really necessary either because that version is not linked into the same > binary as is the version in libs/libc/spawn. > > I suppose a user could enable CONFIG_LIB_SYSCALL in a FLAT build. Then > both would be linked into the same blob, but that is kind of a useless > configuration.
Yes, this is what my current config has. I am trying to port my cRTOS design to newer nuttx. While running in FLAT build, I load Linux binaries in SystemV ABI and hook the system calls redirect them to Nuttx APIs. Of course, I can do this in a kernel build, but I want to keep things simple. I agree that using system calls in a FLAT build is quite meaning less. However, I think we can somehow keep this flexibility for exploiting for binary compability? -- Yang 2020年5月31日(日) 1:07 Gregory Nutt <spudan...@gmail.com>: > > > > Any static should be conditioned on CONFIG_LIB_SYSCALL for the > > task_spawn() version in sched/task/task_spawn.c, however, that is not > > really necessary either because that version is not linked into the > > same binary as is the version in libs/libc/spawn. > > > > I suppose a user could enable CONFIG_LIB_SYSCALL in a FLAT build. > > Then both would be linked into the same blob, but that is kind of a > > useless configuration. > > > So, I think the preferred fix would simply to make CONFIG_LIB_SYSCALL > dependent on !CONFIG_BUILD_FLAT in the Kconfig file. > > -- Yang Chung Fan (楊宗凡) (ヤン ゾン ファン) Member of Softlab, Tsukuba University , Japan Email: sonic.tw...@gmail.com