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

Remove unix-specific fPIC flag #399

Merged
merged 2 commits into from
Dec 21, 2023
Merged

Conversation

mjcarroll
Copy link
Contributor

The exec_program call now raises a cmake warning in sufficiently new cmake versions, it was first triggered here: https://build.osrfoundation.org/job/gz_plugin-ci-pr_any-homebrew-amd64/4/cmake/

With the warning: Policy CMP0153 is not set: The exec_program command should not be called.

The policy is introduced in 3.28, which is probably why we are seeing it on homebrew first: https://cmake.org/cmake/help/latest/policy/CMP0153.html


Once I started looking at what was happening here, though, I think that we can remove the logic entirely.

Some things I noticed that I think are wrong:

  • We are explicitly overriding CMAKE_SYSTEM_PROCESSOR with the contents of uname.
    • In the default case CMAKE_SYSTEM_PROCESSOR should be set to CMAKE_HOST_SYSTEM_PROCESSOR (See https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html)
    • In the cross compilation case, the toolchain file sets CMAKE_SYSTEM_PROCESSOR
    • That means this is at best duplicate work, but is incorrectly overriding CMAKE_SYSTEM_PROCESSOR if someone is cross-compiling (I don't think we currently support this, but this would make it impossible).
  • We are adding fPIC to libraries for x86_64 processors.
    • This should actually be controlled with https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html
    • POSITION_INDEPENDENT_CODE is automatically added in the case of MODULE or SHARED library types, which would be the same as the logic here.
    • We are also excluding ARM/ARM64 in this logic, but I think it doesn't matter because CMake is already doing the right thing under the hood.

Signed-off-by: Michael Carroll <[email protected]>
@github-actions github-actions bot added 🌱 garden Ignition Garden 🎵 harmonic Gazebo Harmonic labels Dec 21, 2023
Copy link
Contributor

@azeey azeey left a comment

Choose a reason for hiding this comment

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

Makes sense to me. Not sure why these were needed in the first place.

@azeey
Copy link
Contributor

azeey commented Dec 21, 2023

cc @claraberendsen

@j-rivero j-rivero merged commit 5624119 into gz-cmake3 Dec 21, 2023
10 checks passed
@j-rivero j-rivero deleted the mjcarroll/remove_exec_program branch December 21, 2023 21:38
mjcarroll added a commit to gazebosim/gz-rendering that referenced this pull request Jan 4, 2024
This was broken by gazebosim/gz-cmake#399, since
we dropped the gazebo-specific flag, we can use native CMake mechanism
for marking this library position-independent.

Signed-off-by: Michael Carroll <[email protected]>
mjcarroll added a commit to gazebosim/gz-rendering that referenced this pull request Jan 4, 2024
This was broken by gazebosim/gz-cmake#399, since
we dropped the gazebo-specific flag, we can use native CMake mechanism
for marking this library position-independent.

Signed-off-by: Michael Carroll <[email protected]>
mderbaso-deepx pushed a commit to DeepX-inc/gz-rendering that referenced this pull request Jun 6, 2024
This was broken by gazebosim/gz-cmake#399, since
we dropped the gazebo-specific flag, we can use native CMake mechanism
for marking this library position-independent.

Signed-off-by: Michael Carroll <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🌱 garden Ignition Garden 🎵 harmonic Gazebo Harmonic
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants