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

Macos linking warning due to visibility #27462

Open
GiudGiud opened this issue Apr 24, 2024 · 5 comments
Open

Macos linking warning due to visibility #27462

GiudGiud opened this issue Apr 24, 2024 · 5 comments
Assignees
Labels
C: Environment P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@GiudGiud
Copy link
Contributor

GiudGiud commented Apr 24, 2024

Bug Description

We get these warnings for classes using templated members (especially the variables)

ld: warning: direct access in function 'AdvectiveFluxAux::AdvectiveFluxAux(InputParameters const&)' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/auxkernels_Unity.aarch64-apple-darwin20.0.0.devel.o' to global weak symbol 'typeinfo for MooseVariableFV<double>' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/variables_Unity.aarch64-apple-darwin20.0.0.devel.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'AdvectiveFluxAux::AdvectiveFluxAux(InputParameters const&)' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/auxkernels_Unity.aarch64-apple-darwin20.0.0.devel.o' to global weak symbol 'typeinfo for MooseVariableFV<double>' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/variables_Unity.aarch64-apple-darwin20.0.0.devel.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'AdvectiveFluxAux::AdvectiveFluxAux(InputParameters const&)' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/auxkernels_Unity.aarch64-apple-darwin20.0.0.devel.o' to global weak symbol 'typeinfo for MooseVariableField<double>' from file '/Users/giudgl/projects/moose/framework/build/unity_src/.libs/variables_Unity.aarch64-apple-darwin20.0.0.devel.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

I looked into it and I think the templates are compiled in several translation unit, and the typeinfo attribute is inlined in one of them and not the other.
Then because we pass this flag: -fvisibility-inlines-hidden, this leads to an inconsistent visibility

A few things I have looked into:

  • -fvisibility=hidden definitely makes everything hidden and consistent. But it prevents linking downstream code unless we go and make everything we need public (not hidden)
  • -linkonce-templates not widely available but could help?
  • attributes (type_visibility notably) on the variables. It does not seem to work so far

@cticenhour looked into this for M1 support too. I dont know if there is an issue dedicated to this problem

Steps to Reproduce

Compile then link on mac

Impact

Distraction. It's 400 lines of warning, that on a smaller screen takes 2000 lines on terminal

@GiudGiud GiudGiud added P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations. labels Apr 24, 2024
@cticenhour
Copy link
Member

I thought I had made an issue, but cannot find it. Thanks @GiudGiud. Assigning this to myself since I still plan to work on it.

@cticenhour cticenhour self-assigned this Apr 24, 2024
@cticenhour
Copy link
Member

A couple contextual notes:

  • I have tried applying -fvisibility=hidden and -fvisibility-inlines-hidden. Mostly at the level of our package environment variables, but on suspicion that PETSc is overriding some of these (they are), I have added them directly into the PETSc build process. Some of these common warnings are coming out of Eigen (hence the PETSc-level troubleshooting). But this was ineffective.
  • -linkonce-templates is not something I have explored.

After speaking with @permcody about this a while back, I'm currently exploring whether how we do explicit template instantiation in our combined non-AD/AD classes may be contributing here.

Probably forgetting some details of things I tried a few months ago....

@GiudGiud
Copy link
Contributor Author

So I think the explicit template instantiations is the right lead for most of the errors

If you look at the errors, the majority of them come from templates that are strictly in moose

nmnobre added a commit to farscape-project/moose that referenced this issue Apr 25, 2024
nmnobre added a commit to farscape-project/moose that referenced this issue Apr 25, 2024
nmnobre added a commit to farscape-project/moose that referenced this issue Apr 25, 2024
@GiudGiud
Copy link
Contributor Author

@nmnobre I see you have unrelated commits linking to this issue. If they go to a PR please amend them first :)

@nmnobre
Copy link
Member

nmnobre commented Apr 28, 2024

Yep, that was a mistake. I’ve amended them and that PR has already been merged, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Environment P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

3 participants