RTEMS | pipe() selection between cpukit and rtems-libbsd depends on link order (#5672)

[Sang Woo Kim (@physwkim)]

Issue created by Sang Woo Kim: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5672



rtems-libbsd!153 adds pipe() and pipe2() backed by the libbsd kernel; cpukit has its own pipe() in `cpukit/libfs/src/pipe/pipe.c`. Both definitions are strong, so which one an application gets is decided by archive order on the link line — `-lbsd` happens to be searched first, and nothing enforces that. A changed order silently selects the FIFO-based implementation, whose descriptors do not work with libbsd select()/poll()/kqueue(), and if both objects are ever pulled the link fails with a duplicate definition.

Proposal: mark the cpukit definition `RTEMS_WEAK` (precedent: `_Malloc_Process_deferred_frees`). A strong libbsd definition then overrides deterministically, and applications without libbsd keep the cpukit implementation. From the discussion in rtems-libbsd!153 (note 155890).

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5672
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-euflr9uxkp3ostw901n0rlkwb-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260730/6c3b3b00/attachment.htm>