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

wasm_export.h: Use "default" visibility #3957

Merged
merged 1 commit into from
Dec 19, 2024

Conversation

midokura-xavi92
Copy link
Contributor

Since the top-level CMakelists.txt is appending -fvisibility=hidden to the compile options, no public symbols are exported by default. This forbids users from linking against the shared library.

Using gcc/clang attributes 1, it is possible to override the definition for WASM_RUNTIME_API_EXTERN so that only required symbols are correctly exported.

  • Before the patch:
$ nm build/libiwasm.so | grep -e 'wasm_runtime_get_version'
00000000000419e9 t wasm_runtime_get_version
  • After the patch:
$ nm build/libiwasm.so | grep -e 'wasm_runtime_get_version'
0000000000043c69 T wasm_runtime_get_version

Since the top-level CMakelists.txt is appending -fvisibility=hidden to
the compile options, no public symbols are exported by default. This
forbids users from linking against the shared library.

Using gcc/clang attributes [1], it is possible to override the
definition for WASM_RUNTIME_API_EXTERN so that only required symbols are
correctly exported.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
@lum1n0us
Copy link
Collaborator

Please review the changes at #3655. I trust you'll find the information useful.

@midokura-xavi92
Copy link
Contributor Author

Please review the changes at #3655. I trust you'll find the information useful.

Despite these concerns, I have successfully built this branch i.e., without any undefined references. Is there anything else I should take into account?

As far as I understand, functions such as os_mmap or b_memcpy_s are built from different executables or libraries, so they remain unaffected by iwasm_static or iwasm_shared and the visibility of their symbols. In other words, relevant CMakeLists.txt would include (${SHARED_DIR}/utils/uncommon/shared_uncommon.cmake) directly so as to import the source files that define such symbols.

@lum1n0us
Copy link
Collaborator

@bnason-nf @yamt Please review this. Ensure that it does not conflict with your previous plans.

Copy link
Collaborator

@lum1n0us lum1n0us left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bnason-nf
Copy link
Contributor

Thanks for the heads up @lum1n0us. I think this should be ok, but I would need to test more to be sure. I think it's fine to merge and we can revisit later if it causes any problems for me.

@yamt
Copy link
Collaborator

yamt commented Dec 18, 2024

@bnason-nf @yamt Please review this. Ensure that it does not conflict with your previous plans.

honestly speaking, i don't remember the previous discussion well.
this patch itself looks reasonable to me.

@midokura-xavi92 if you care these stuff, you might want to improve the CI coverage.
iirc, our CI coverage on shared library and relevant things is pretty low.
cf. #3687

@wenyongh wenyongh merged commit 296c3cc into bytecodealliance:main Dec 19, 2024
383 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants