Project

General

Profile

Bug #549

install-mdrun rule does not install shared libs (CMake)

Added by Szilárd Páll about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

When building with shared libs on and installing only the mdrun binary (make install-mdrun), the libraries it's linked against are not installed.

Reported on the user's list: http://lists.gromacs.org/pipermail/gmx-users/2010-September/053763.htm

Use_CMake_Install_For_mdrun.patch (10.6 KB) Use_CMake_Install_For_mdrun.patch Preliminary patch for using CMake mechanisms for install-mdrun Teemu Murtola, 10/13/2010 05:15 PM

Related issues

Has duplicate GROMACS - Bug #540: problem with mdrun-gpu and version 4.5.1Closed09/02/2010
Blocks GROMACS - Bug #570: CMake binaries with shared libs won't run correctly without installing (Ubuntu CMake 2.6.2)Closed09/21/2010

Associated revisions

Revision 36133dbe (diff)
Added by Teemu Murtola about 9 years ago

Use CMake install for install-mdrun (bugs #549, #555)

The custom target install-mdrun now invokes the cmake_install.cmake
script that is generated by CMake to perform the actual installation.
Adds support for DESTDIR and RPATH rewriting (see bug #570).

To implement this, all installation targets are now grouped into
components: "data" for shared data, "development" for headers and
pkgconfig files, "libraries" for libraries needed by mdrun, "mdrun" for
mdrun itself, and "runtime" for other binaries and libraries. Only
"mdrun" and "libraries" are used at the moment (the latter only when
installing with shared libraries).

Haven't tested this with Visual Studio, but if it doesn't work, it
should be easy to adapt.

History

#3 Updated by Szilárd Páll about 9 years ago

Fixed in a39d22e1564. Please, test it!

#4 Updated by Teemu Murtola about 9 years ago

I think that if bug #570 gets fixed, there are still issues, because the mdrun binary gets copied with cmake -E copy instead of FILE. The latter is supposed to fix RPATHs etc.; I'm not sure whether this affects only the binary or also somehow the libraries themselves. Using FILE should also fix the DESTDIR bug #555.

#5 Updated by Szilárd Páll about 9 years ago

(In reply to comment #4)

I think that if bug #570 gets fixed, there are still issues, because the mdrun
binary gets copied with cmake -E copy instead of FILE. The latter
is supposed to fix RPATHs etc.; I'm not sure whether this affects only the
binary or also somehow the libraries themselves. Using FILE
should also fix the DESTDIR bug #555.

True, thanks for pointing it out, this is what I was referring to in comment #5 to 570 (http://bugzilla.gromacs.org/show_bug.cgi?id=570#c5). I am not very familiar with the rpath magic, but I'll look into it.

@Teemu: are you working 570? Will it make it into 4.5.2? I am asking because ATM this is not a bug, but if 570 get fixed it will turn into one, but I might not have time to fix it by tomorrow.

What do you think, is there an issue with the additional "make install-gmx|gmxpreprocess|md" I generate and which also use cmake -E copy or those are fine, only the binary needs to be file(INSTALL...)-ed?

#6 Updated by Szilárd Páll about 9 years ago

(In reply to comment #4)

I've just checked the CMake documentation and could not find the file(INSTALL ...) command. Have I overlooked something?

#7 Updated by Teemu Murtola about 9 years ago

(In reply to comment #5)

@Teemu: are you working 570? Will it make it into 4.5.2? I am asking because
ATM this is not a bug, but if 570 get fixed it will turn into one, but I might
not have time to fix it by tomorrow.

I figured out the part of our CMakeLists.txt that causes bug #570 (just search for RPATH in the root file), but I'm waiting for Erik to comment on why he added those lines in the first place. I think we can leave that post-4.5.2.

What do you think, is there an issue with the additional "make
install-gmx|gmxpreprocess|md" I generate and which also use cmake -E copy or
those are fine, only the binary needs to be file(INSTALL...)-ed?

I checked, and readelf -d shows that also the shared libraries have RPATHs encoded in them. So, if we fix the RPATHs to point to the build tree, there will also be issued with cmake -E copy with the library files.

As for FILE, it seems that it's only documented in CMake 2.8, and even there only partially (it's in the end of the FILE command documentation, separate from all the rest); it is still the internal mechanism that is used even in CMake 2.6, e.g., for "make install". If we don't want to depend in this command directly, we might try to make it so that also "make install-mdrun" would run "cmake -P cmake_install.cmake" with some additional flags set (-DCMAKE_INSTALL_COMPONENT=something with suitable changes in the install() commands in the CMake input files might do the trick). "make install" seems to run this script without any flags.

#8 Updated by Szilárd Páll about 9 years ago

There's a strange issue with the "make install-mdrun" which I'd need tips on how to fix.

Basically, the issue is that "make install-mdrun" chokes if the bin directory is not created before issuing the command. However, what's strange is that e.g. make install-gmx which installs the libgmx.so library does not fail, but creates the dir.

Any idea what could be wrong?

#9 Updated by Teemu Murtola about 9 years ago

Created an attachment (id=556)
Preliminary patch for using CMake mechanisms for install-mdrun

To continue the discussion on whether we would like to use the CMake internal mechanisms for install-mdrun, I attached a preliminary patch that actually does that. What do you think? RPATH rewriting and DESTDIR should both work, and there is much less code than there used to be. While I was at it, I added a COMPONENT specification to all install() commands, but that should probably be thought about a bit more.

#10 Updated by Szilárd Páll about 9 years ago

(In reply to comment #9)

Created an attachment (id=556) [details]
Preliminary patch for using CMake mechanisms for install-mdrun

To continue the discussion on whether we would like to use the CMake internal
mechanisms for install-mdrun, I attached a preliminary patch that actually does
that. What do you think? RPATH rewriting and DESTDIR should both work, and
there is much less code than there used to be. While I was at it, I added a
COMPONENT specification to all install() commands, but that should probably be
thought about a bit more.

I think it's great, it seems to work well and it indeed is way more simple!

For what else are the components good for (except CPack)?

#11 Updated by Teemu Murtola about 9 years ago

(In reply to comment #10)

I think it's great, it seems to work well and it indeed is way more simple!

I haven't tried with Visual Studio, but a quick Google search suggests that projects generated with CMake use cmake_install.cmake for installation with Visual Studio as well. So even if my exact patch wouldn't work, it should be relatively easy to adapt to that case as well. The only ugly thing in this patch is that it relies on poorly documented internal features of the CMake generators, but I still think the advantages outweigh this. If there are no objections, I'll push this to the release-4-5-patches branch.

For what else are the components good for (except CPack)?

I don't know, they don't seem to be documented very well... The generated makefile has a list_install_components target, but I haven't figured out whether there is anything else related to this.

#12 Updated by Teemu Murtola about 9 years ago

The proposed patch has now been added as commit 36133dbe2037f86b2791771259cbed6058886948, with only slight changes to the way things are divided into components. If someone could test that this works also on Visual Studio (if we want that), that would be great.

Also available in: Atom PDF