Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not export internal symbols in shared object files (libraries) #1304

Open
jrohel opened this issue Mar 12, 2024 · 0 comments · May be fixed by #1307
Open

Do not export internal symbols in shared object files (libraries) #1304

jrohel opened this issue Mar 12, 2024 · 0 comments · May be fixed by #1307
Assignees
Labels
Priority: LOW RFE Request For Enhancement (as opposed to a bug) Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take

Comments

@jrohel
Copy link
Contributor

jrohel commented Mar 12, 2024

Now, all symbols that are not marked static or placed in an anonymous namespace are exported in a shared object. Thus, internal symbols are exported as ABI.

  • Users can use interfaces they should not use
  • Internal library changes change exported symbols - ABI compatibility problem.
  • The dynamic symbol table and its string table are available at run-time and therefore must be loaded. This require memory. And CPU time at startup (relocations, ...).
@jrohel jrohel self-assigned this Mar 12, 2024
@ppisar ppisar added RFE Request For Enhancement (as opposed to a bug) Priority: LOW Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take labels Mar 12, 2024
@jrohel jrohel linked a pull request Mar 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: LOW RFE Request For Enhancement (as opposed to a bug) Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants