Skip to content

GH-46714: [C++] Use hidden symbol visibility in Meson configuration #46715

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

WillAyd
Copy link
Contributor

@WillAyd WillAyd commented Jun 4, 2025

Rationale for this change

This will eventually make it easier to support Windows through the Meson configuration, while also providing the documented benefits of hidden symbol visibility

What changes are included in this PR?

Meson libraries have been set to use hidden symbol visibility, and corresponding definitions have been updated to use the ARROW_EXPORT macro

Are these changes tested?

Yes

Are there any user-facing changes?

No

@WillAyd WillAyd requested a review from westonpace as a code owner June 4, 2025 21:37
@WillAyd WillAyd added the CI: Extra Run extra CI label Jun 4, 2025
Copy link

github-actions bot commented Jun 4, 2025

⚠️ GitHub issue #46714 has been automatically assigned in GitHub to PR creator.

@WillAyd
Copy link
Contributor Author

WillAyd commented Jun 4, 2025

FWIW the hidden symbol visibility appears to shave a couple MB off of the libarrow release size (43MB -> 41 MB locally)

@@ -260,7 +260,9 @@ bool Expression::Equals(const Expression& other) const {
return false;
}

bool Identical(const Expression& l, const Expression& r) { return l.impl_ == r.impl_; }
ARROW_EXPORT bool Identical(const Expression& l, const Expression& r) {
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to use ARROW_EXPORT in .cc not .h?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had some dejavu on this and we actually discussed this over a year ago back in #41872 (comment)

It looks like with clang and gcc 12+ this is required to be attached to the definition.

Alternatively, maybe we can make this not a friend qualified method in the header?

Copy link
Member

Choose a reason for hiding this comment

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

Oh!

@pitrou Do you have any opinion for this?

Copy link
Member

Choose a reason for hiding this comment

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

This could easily be a static method on Expression instead of a friend function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've tried to move as many of these from the module to the header; however, I do not think the default visibility for the friend methods can be moved to the header, but rather must be attached to the definition:

https://stackoverflow.com/a/52332379/621736

I suppose we could alternatively move the friend definitions into the header files?

As an aside, it looks like the code base currently has an incomplete (?) macro intended for use with friends, ARROW_FRIEND_EXPORT:

// For some reason [[gnu::dllexport]] doesn't work well with friend declarations

This is perhaps facing the limitation with friend exports needing to be attached to the definition linked above. Maybe this should be removed?

@github-actions github-actions bot added awaiting changes Awaiting changes and removed awaiting review Awaiting review labels Jun 5, 2025
@pitrou
Copy link
Member

pitrou commented Jun 5, 2025

This will eventually make it easier to support Windows through the Meson configuration

Why is that?

@@ -81,6 +81,7 @@ arrow_acero_lib = library(
'arrow-acero',
sources: arrow_acero_srcs,
dependencies: [arrow_dep],
gnu_symbol_visibility: 'hidden',
Copy link
Member

Choose a reason for hiding this comment

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

Does it also work with clang or is it gcc-specific?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This works with clang as well

@WillAyd
Copy link
Contributor Author

WillAyd commented Jun 5, 2025

This will eventually make it easier to support Windows through the Meson configuration

Why is that?

The idea is just that Windows has a harder requirement around symbols not being public by default. Of course, there are extra macros that would need to be defined to fully support the Windows linker requirements, but this is at least a sanity check that we are exporting the right symbols. I am also under the assumption that most developers are on *nix platforms, so it helps them detect potential symbol export issues sooner, rather than waiting for them to pop up in Windows CI

@pitrou
Copy link
Member

pitrou commented Jun 5, 2025

It would be nice to try applying those changes on the CMake side as well. I agree that it would be good hygiene to have to mark exported symbols explicitly.

@github-actions github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Jun 6, 2025
@WillAyd
Copy link
Contributor Author

WillAyd commented Jun 6, 2025

It would be nice to try applying those changes on the CMake side as well. I agree that it would be good hygiene to have to mark exported symbols explicitly.

Any objection to doing this as a follow up? I did try that previously and ran into issues with some of the downstream crossbow jobs specifically on macOS, so I'm a bit hesitant to be opening a pandora's box with the CMake config in this PR

@pitrou
Copy link
Member

pitrou commented Jun 9, 2025

No, it's fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting change review Awaiting change review CI: Extra Run extra CI Component: C++
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants