Having modified libc to not expose sbrk for linking, provide a library
that links to the versioned symbol and exposes sbrk for linking. This
allows software that requires sbrk to add -lsbrk to LDFLAGS to use sbrk
without allowing autoconf to overzealously find it via AC_CHECK_FUNC.
Details
- Reviewers
kib
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 58254 Build 55142: arc lint + arc unit
Event Timeline
This is an incomplete proof of concept of a library to expose sbrk. One could also expose brk, but AFACT there are no users of it. I've done some simple testing with explicit linkage and LD_LIBRARY_PATH. In that context it seems to work.
It's not clear to me that this would actually belong in the base system, on one hand it's trivial, on the other hand it might be a better fit in ports since there are only two sbrk using tests and no programs in the tree.
This sbrk symbol should be versioned as well.
Also, the library might be filter for libc.
lib/libsbrk/sbrk.c | ||
---|---|---|
41 |
I don't object to doing that, but I'm not super convinced it's useful. There will never be a change to sbrk's interface. Should it be FBSD_1.0 like it is in libc or FBSD_1.8 because it's from FreeBSD 15?
Also, the library might be filter for libc.
That would make it linkable by default which would cause the problem I'm trying to avoid.
FBSD_1.0. dlvsym() should work unchanged for this lib.
Also, the library might be filter for libc.
That would make it linkable by default which would cause the problem I'm trying to avoid.
But only if -lsbrk is provided to linker. Isn't it the goal?
Also, what about static linking? Should the symbol still be resolved from libc.a or we need libsbrk.a as well?
[Just in case, libdl.so is filter]
Why not provide the symbol and lib on aarch64/riscv as well? It only makes porting sw harder IMO.
rescue/rescue/Makefile | ||
---|---|---|
149 | How is this chunk related to the introduction of the new library? |