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

don't set rpath #203

Merged
merged 1 commit into from
Feb 7, 2017
Merged

Conversation

rojkov
Copy link
Contributor

@rojkov rojkov commented Jan 27, 2017

When building with OpenEmbedded the lib's rpath is set to
/usr/lib which is redundant and reported as a QA issue.

Signed-off-by: Dmitry Rozhkov [email protected]

@jslee02
Copy link
Member

jslee02 commented Feb 2, 2017

I don't know much about RPATH. It would be great if someone else reviews this PR.

@traversaro
Copy link
Contributor

traversaro commented Feb 3, 2017

Using RPATH on installation binaries can be extremely convenient in some cases (when installing the library in non-standard location or using a cmake superbuild) and undesirable in other cases (for example during debian packaging, see https://wiki.debian.org/RpathIssue).

As the desirable RPATH behavior changes between different use cases, I suggest adding the CMAKE_SKIP_INSTALL_RPATH a CMake option that controls the RPATH behavior, and leave its default value to the current behavior. I assume then that the option can then be disabled when building with OpenEmbedded.

In our projects we use the AddInstallRPATHSupport CMake macro to obtain this:
https://github.com/robotology/ycm/blob/v0.2.2/modules/AddInstallRPATHSupport.cmake .

@rojkov
Copy link
Contributor Author

rojkov commented Feb 7, 2017

Yep, makes sense to keep the original behavior by default to avoid unexpected breakages:

  • made the current RPATH behavior optional with the default to keep the original settings;
  • rebased and force pushed.

set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_LIBDIR_FULL}")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
endif(NO_DEFAULT_RPATH)
Copy link
Contributor

Choose a reason for hiding this comment

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

The style used in fcl's CMakeLists (at least in this one) is to avoid keeping the condition in the endif(), I would suggest removing this.

# By default CMake sets RPATH for binaries in the build tree, but clears
# it when installing. Switch this option off if the default behaviour is
# desired.
option(NO_DEFAULT_RPATH "Set RPATH for installed binaries" ON)
Copy link
Contributor

Choose a reason for hiding this comment

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

All FCL CMake options that are not global CMake options (such as BUILD_SHARED_LIBS or BUILD_TESTING) are prefixed with FCL_, I suggest to use the same convention here. Furthermore given that this is a rather advanced option, I suggest marking it as advanced using mark_as_advanced.

@traversaro
Copy link
Contributor

@jslee02 I have some minor style remarks, but other then that I think that the logic is ok now.

The currently used compiler settings explicitly set RPATH to
installed binaries which is not desired behaviour in some
circumstances, e.g. OpenEmbedded's QA checks report an issue
about redundant RPATH set to the standard '/usr/lib' directory.

This patch adds the configure option FCL_NO_DEFAULT_RPATH which is
ON by default in order to preserve the current behaviour, but
when set to OFF make CMake use its default RPATH settings, that is
set RPATH for the binaries in the build tree, but clear them out
for installed binaries.

Signed-off-by: Dmitry Rozhkov <[email protected]>
@rojkov
Copy link
Contributor Author

rojkov commented Feb 7, 2017

Addressed the review comments and force pushed.

@jslee02 jslee02 added this to the FCL 0.6.0 milestone Feb 7, 2017
@jslee02
Copy link
Member

jslee02 commented Feb 7, 2017

It looks good to me. Thanks @rojkov and @traversaro ! Merging this RP.

@jslee02 jslee02 merged commit 2e3d262 into flexible-collision-library:master Feb 7, 2017
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.

3 participants