Open apprehensions opened 5 months ago
Bug in basu: https://todo.sr.ht/~emersion/basu/20
That basu bug is unrelated. Version scripts are only applied to dynamic libraries.
So what is the issue here?
@apprehensions The issue is that both sway and basu define a publicly visible function named parse_boolean()
. Since C has no namespacing, there is no way for the linker to know which of the two functions to take. With dynamic linking this is slightly less of a problem, since the binary and the library are linked separately (with only one parse_boolean()
function visible) and when loading each shared object just uses its own definition of parse_boolean()
before attempting to resolve it from a library.
This is a common problem in C and the solution is usually to rename the function in the library to include a prefix, such as basu_parse_boolean()
. A similar issue happened with libdecor a while ago.
The question is why is basu's function global?
IIUC there is no way in standard C to make a function available in a different file without making it global. I think you can do things with visibility attributes in nonstandard C, but I have never figured out how exactly that works, I'm not sure how those interact with static linking, and it's always a pain.
Visibility attributes only affect dynamic linking.
Visibility attributes only affect dynamic linking.
I expected something like that, but didn't know exactly. So the only option is to rename the functions in at least one of the two projects so it doesn't clash any more.
IMO this is a bug in the library (basu in this case)
Please fill out the following:
Reproduction Steps
Logs