Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

Static library contains private symbols #1892

Open
emersion opened this issue Nov 1, 2019 · 3 comments · Fixed by #2969
Open

Static library contains private symbols #1892

emersion opened this issue Nov 1, 2019 · 3 comments · Fixed by #2969
Labels

Comments

@emersion
Copy link
Member

emersion commented Nov 1, 2019

Follow-up issue for swaywm/sway#4677

Potential solutions:

  • Find a way to strip our private symbols for the static library, just like the version script we have for the dynamic library
  • Prefix our private functions (but then the version script won't work anymore, at least if we prefix with wlr_)

cc @sheenobu


wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1892

@kennylevinsen
Copy link
Member

  • We can't strip private symbols from a static library. While shared libraries are linked binaries with a global symbol table that can be adjusted/filtered, static libraries aren't linked at all, and are just object files stuffed in an archive. Hiding a symbol also hides it from the other parts of wlroots that might need it.
    • Fixing this would require a tool that could "link" object files so that internal dependencies could be resolved and turned static, and output a new bare object file. Haven't found such tool so far.
  • Renaming symbols to hide them seems to imply using objcopy to modify the library first, which seems a little nasty.
  • Prefixing is possible, but either requires a different prefix or a changed version script as mentioned.

@progandy
Copy link

Prefix our private functions (but then the version script won't work anymore, at least if we prefix with wlr_)

Isn't it common to prefix private symbols with an underscore, i.e. _wlr_?

@emersion
Copy link
Member Author

emersion commented Jun 7, 2021

I'd be fine with a _wlr prefix FWIW.

kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
kennylevinsen added a commit to kennylevinsen/wlroots that referenced this issue Jun 14, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: swaywm#1892
Closes: swaywm#2952
emersion pushed a commit that referenced this issue Jun 17, 2021
Static libraries are not affected by our symbol file, so private symbols
are globally visible by default.

Use objcopy to make symbols that we do not want to expose local.

Closes: #1892
Closes: #2952
@emersion emersion reopened this Sep 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

Successfully merging a pull request may close this issue.

3 participants