swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.71k stars 1.11k forks source link

Fails to link with statically linked basu #8186

Open apprehensions opened 5 months ago

apprehensions commented 5 months ago

Please fill out the following:

Reproduction Steps

  1. Install basu as a statically linked library
  2. Build sway

Logs

[124/318] Compiling C object sway/sway.p/commands_input_xkb_switch_layout.c.o
ninja: job failed: cc  -o swaybar/swaybar swaybar/swaybar.p/meson-generated_.._.._protocols_xdg-shell-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_xdg-output-unstable-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_pointer-constraints-unstable-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_tablet-unstable-v2-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_linux-dmabuf-unstable-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_content-type-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_cursor-shape-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_wlr-layer-shell-unstable-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_idle-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_wlr-input-inhibitor-unstable-v1-protocol.c.o swaybar/swaybar.p/meson-generated_.._.._protocols_wlr-output-power-management-unstable-v1-protocol.c.o swaybar/swaybar.p/bar.c.o swaybar/swaybar.p/config.c.o swaybar/swaybar.p/i3bar.c.o swaybar/swaybar.p/input.c.o swaybar/swaybar.p/ipc.c.o swaybar/swaybar.p/main.c.o swaybar/swaybar.p/render.c.o swaybar/swaybar.p/status_line.c.o swaybar/swaybar.p/tray_host.c.o swaybar/swaybar.p/tray_icon.c.o swaybar/swaybar.p/tray_item.c.o swaybar/swaybar.p/tray_tray.c.o swaybar/swaybar.p/tray_watcher.c.o -Wl,--as-needed -Wl,--no-undefined -O3 -pipe -march=native -Wno-error=switch -Wl,--start-group common/libsway-common.a client/libsway-client.a /usr/lib/libcairo.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libjson-c.so -lm /usr/lib/libpango-1.0.so /usr/lib/libharfbuzz.so /usr/lib/libpangocairo-1.0.so -lrt /usr/lib/libwayland-client.so /usr/lib/libwayland-cursor.so /usr/lib/libbasu.a -pthread /usr/lib/libcap.so -Wl,--end-group
/usr/bin/ld: /usr/lib/libbasu.a(parse-util.c.o): in function `parse_boolean':
(.text+0x0): multiple definition of `parse_boolean'; common/libsway-common.a.p/util.c.o:/home/sewn/.cache/kiss/proc/5637/build/sway/build/../common/util.c:41: first defined here
collect2: error: ld returned 1 exit status
ninja: subcommand failed
apprehensions commented 5 months ago

Bug in basu: https://todo.sr.ht/~emersion/basu/20

emersion commented 5 months ago

That basu bug is unrelated. Version scripts are only applied to dynamic libraries.

apprehensions commented 5 months ago

So what is the issue here?

Ferdi265 commented 5 months ago

@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.

apprehensions commented 5 months ago

The question is why is basu's function global?

Ferdi265 commented 5 months ago

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.

emersion commented 5 months ago

Visibility attributes only affect dynamic linking.

Ferdi265 commented 5 months ago

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)