Installing 2 versions of PCL in the same machine and switching between them

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Installing 2 versions of PCL in the same machine and switching between them

rojas70
Greetings,

Running Linux Ubuntu 14.04 with PCL 1.7.1-x. Want to run some open source
code that dates a few years back where they are using PCL 1.6.

I realize I need to install PCL 1.6 from source, but I am not so sure about
any potential conflicts that that will cause.

I guess 1.6 could be installed locally or into the filesystem... If locally,
how to get CMakeLists to detect the local version?

If installed into the filesystem, I guess:
/usr/bin files... get overwritten
/usr/include/ creates a new folder: pcl-1.6/pcl in addition to pcl-1.7/pcl
/usr/lib gets new libs for 1.6, like libpcl_xxx.so.1.6 and soft links would
have to be updated
/usr/share gets a new pcl-1.6 folder with CMake config files.

These could be used in other CMakeFiles by using the find_package(PCL 1.6
EXACT).

I would appreciate some further feedback on this.
Thanks




--
Sent from: http://www.pcl-users.org/
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Installing 2 versions of PCL in the same machine and switching between them

Stephen McDowell
Typically, /usr/{bin,lib,include} are not where you install things if you need multiple versions.  For the exact reason you show — the executables do not typically get stashed underneath their own directory.  The reason is mostly for simplicity.  If you had

/usr/bin/pcl-1.6/cloud-viewer
/usr/bin/pcl-1.7/cloud-viewer

then the user must now put something like

export PATH=“/usr/bin/pcl-1.6:$PATH”

in their startup scripts (e.g., ~/.bashrc).  On the other hand, /usr/bin is pretty much guaranteed to be in the $PATH on every unix system I’ve ever used.

!!! NOTE !!! my e-mail client is putting in UTF “curly quotes” so be careful copy-pasting, make sure you are using regular quotes in your terminal (e.g., don’t copy-paste, just type it out!)

So here are three options I would consider, definitely try (1) first because it should be the easiest:

1. It may actually be OK to use PCL 1.7 with this older library.  If they had `find_package(PCL 1.6 EXACT)` in there, it’s likely that 1.6 was the latest release at the time and that’s what they wanted to make sure users had.  E.g., there was a specific component introduced in 1.6 that was not previously unavailable.  Other users of this mailing list may know whether or not this is true, but I doubt there are any API breaking changes between 1.6 and 1.7.  Probably just new things added / bug fixes etc.

So you can modify the project you are building to try and use `find_package(PCL 1.6 REQUIRED)`.  Technically if / when PCL 2.0 comes around, this will no longer work, but that’s likely a long way off.  Changing EXACT to REQUIRED should accept 1.7 as well, the 1.6 saying “at least this version” now that REQUIRED is being used.

Side note: if it does work, it might be nice of you to submit a pull request changing EXACT to REQUIRED to the library :)

2. If it turns out that the application is not capable of building with 1.7, the “easy” way of getting this up and running is to install PCL 1.6 in a non-standard location.  With CMake, the way you would do this is something like

$ cd /path/to/repo
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/opt

This tells CMake that, instead of the default /usr/{bin,lib,include}, you want it to install to /opt.  When I do this, I typically keep all of my installations completely isolated.  So instead of /opt I might use something like /opt/pcl_1_6 so that I can delete it safely without affecting other custom installations.

So now, you would need to build PCL as normal and then execute sudo make install since /opt is protected.  Now that it is installed, you have some extra steps to make sure that you can actually use this.  This is where things become a little finessed, since presumably you want to be using PCL 1.7 for your project(s), and are only trying to use PCL 1.6 for this one project.

Note: if you are planning on linking against this other project in your own code, you have to commit to whatever version of PCL you used to compile it.  You cannot link both PCL 1.6 and PCL 1.7 in a project.

So, when you want to build this other project, you have some variables you need to setup

# may not need the executables in your path, this is just for completeness
$ export PATH=“/opt/pcl_1_6:$PATH”
$ export LD_LIBRARY_PATH=“/opt/pcl_1_6/lib:$LD_LIBRARY_PATH”

The first one makes it so the executables are available, the second one makes it so that when the linker is building the project that needs PCL 1.6, the actual library itself can be found.  When you want to run applications that linked against the PCL 1.6 libraries, LD_LIBRARY_PATH must contain the path to the PCL 1.6 libraries in order to run (assuming dynamic libraries, which is very likely).  The last one you need is to enable CMake to actually find this.  This is done using the CMAKE_MODULE_PATH environment variable.  When `find_package` is issued in a CMakeLists.txt, this variable defines where to look first, before checking the standard locations (e.g., under /usr/).  You’ll have to check the installation, it may be different on Linux, but for me on OS X it showed up under /opt/pcl_1_6/share where there were two files

- PCLConfig.cmake
- PCLConfigVersion.cmake

You want to add whatever directory contains these two to the CMAKE_MODULE_PATH

$ export CMAKE_MODULE_PATH=“/opt/pcl_1_6/share:$CMAKE_MODULE_PATH”

By putting them in the front, that means PCL 1.6 will now get found first.

Note: when doing `export X=blah` that changes the environment variable for the current shell only.  Since I assume you want to use PCL 1.7 for most of your stuff, this would be appropriate.  If you need to always use PCL 1.6, then you would want to add these to your startup scripts, e.g. ~/.bashrc.

The implication: if you open a new terminal and try and run the executables built from the library that needs PCL 1.6, you need to issue the above `export ` commands (more specifically, after you’ve built it you will still need to get LD_LIBRARY_PATH setup again).

3. As it turns out, this is a relatively common thing to need to do in the high performance computing world (have multiple different versions of a library available).  Typically it’s so that you can change which version of MPI you are using, or switch between using libraries compiled with GCC vs Intel vs Clang etc.  If you really really really need to be able to conveniently switch between the two, you do this through “Environment Modules”.

To be clear, if you don’t know how to set this up, and can be rather painful.  For this scenario, it’s totally overkill and I do NOT recommend it just for this purpose.

In short, when using multiple different versions of a library, it is the responsibility of the user to coordinate this.  For just a one-off “I need PCL 1.6 for just one library”, just manually install it to somewhere other than /usr.  If you need many different versions of many different libraries, then you would want to invest your time into getting environment modules setup ;)

I hope that was clear enough for you to understand how to proceed, I tried very hard not to skip any details!  Good luck, post back if you’re stuck!

P.S. Note that my approach is only one way to solve this.  This domain is often personal preference, e.g. some people like to install custom builds under ~/apps or something.  You might do that if you do not have `sudo` capabilities on the machine you are building on and therefore cannot execute `sudo make install`.


On Dec 28, 2017, at 7:48 AM, rojas70 <[hidden email]> wrote:

Greetings,

Running Linux Ubuntu 14.04 with PCL 1.7.1-x. Want to run some open source
code that dates a few years back where they are using PCL 1.6.

I realize I need to install PCL 1.6 from source, but I am not so sure about
any potential conflicts that that will cause.

I guess 1.6 could be installed locally or into the filesystem... If locally,
how to get CMakeLists to detect the local version?

If installed into the filesystem, I guess:
/usr/bin files... get overwritten
/usr/include/ creates a new folder: pcl-1.6/pcl in addition to pcl-1.7/pcl
/usr/lib gets new libs for 1.6, like libpcl_xxx.so.1.6 and soft links would
have to be updated
/usr/share gets a new pcl-1.6 folder with CMake config files.

These could be used in other CMakeFiles by using the find_package(PCL 1.6
EXACT).

I would appreciate some further feedback on this.
Thanks




--
Sent from: http://www.pcl-users.org/
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Installing 2 versions of PCL in the same machine and switching between them

Stephen McDowell
Sorry, this was wrong:

# may not need the executables in your path, this is just for completeness
$ export PATH=“/opt/pcl_1_6:$PATH”

You need /opt/pcl_1_6/bin (the extra bin) part was missing!

On Dec 28, 2017, at 10:00 AM, Stephen McDowell <[hidden email]> wrote:

Typically, /usr/{bin,lib,include} are not where you install things if you need multiple versions.  For the exact reason you show — the executables do not typically get stashed underneath their own directory.  The reason is mostly for simplicity.  If you had

/usr/bin/pcl-1.6/cloud-viewer
/usr/bin/pcl-1.7/cloud-viewer

then the user must now put something like

export PATH=“/usr/bin/pcl-1.6:$PATH”

in their startup scripts (e.g., ~/.bashrc).  On the other hand, /usr/bin is pretty much guaranteed to be in the $PATH on every unix system I’ve ever used.

!!! NOTE !!! my e-mail client is putting in UTF “curly quotes” so be careful copy-pasting, make sure you are using regular quotes in your terminal (e.g., don’t copy-paste, just type it out!)

So here are three options I would consider, definitely try (1) first because it should be the easiest:

1. It may actually be OK to use PCL 1.7 with this older library.  If they had `find_package(PCL 1.6 EXACT)` in there, it’s likely that 1.6 was the latest release at the time and that’s what they wanted to make sure users had.  E.g., there was a specific component introduced in 1.6 that was not previously unavailable.  Other users of this mailing list may know whether or not this is true, but I doubt there are any API breaking changes between 1.6 and 1.7.  Probably just new things added / bug fixes etc.

So you can modify the project you are building to try and use `find_package(PCL 1.6 REQUIRED)`.  Technically if / when PCL 2.0 comes around, this will no longer work, but that’s likely a long way off.  Changing EXACT to REQUIRED should accept 1.7 as well, the 1.6 saying “at least this version” now that REQUIRED is being used.

Side note: if it does work, it might be nice of you to submit a pull request changing EXACT to REQUIRED to the library :)

2. If it turns out that the application is not capable of building with 1.7, the “easy” way of getting this up and running is to install PCL 1.6 in a non-standard location.  With CMake, the way you would do this is something like

$ cd /path/to/repo
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/opt

This tells CMake that, instead of the default /usr/{bin,lib,include}, you want it to install to /opt.  When I do this, I typically keep all of my installations completely isolated.  So instead of /opt I might use something like /opt/pcl_1_6 so that I can delete it safely without affecting other custom installations.

So now, you would need to build PCL as normal and then execute sudo make install since /opt is protected.  Now that it is installed, you have some extra steps to make sure that you can actually use this.  This is where things become a little finessed, since presumably you want to be using PCL 1.7 for your project(s), and are only trying to use PCL 1.6 for this one project.

Note: if you are planning on linking against this other project in your own code, you have to commit to whatever version of PCL you used to compile it.  You cannot link both PCL 1.6 and PCL 1.7 in a project.

So, when you want to build this other project, you have some variables you need to setup

# may not need the executables in your path, this is just for completeness
$ export PATH=“/opt/pcl_1_6:$PATH”
$ export LD_LIBRARY_PATH=“/opt/pcl_1_6/lib:$LD_LIBRARY_PATH”

The first one makes it so the executables are available, the second one makes it so that when the linker is building the project that needs PCL 1.6, the actual library itself can be found.  When you want to run applications that linked against the PCL 1.6 libraries, LD_LIBRARY_PATH must contain the path to the PCL 1.6 libraries in order to run (assuming dynamic libraries, which is very likely).  The last one you need is to enable CMake to actually find this.  This is done using the CMAKE_MODULE_PATH environment variable.  When `find_package` is issued in a CMakeLists.txt, this variable defines where to look first, before checking the standard locations (e.g., under /usr/).  You’ll have to check the installation, it may be different on Linux, but for me on OS X it showed up under /opt/pcl_1_6/share where there were two files

- PCLConfig.cmake
- PCLConfigVersion.cmake

You want to add whatever directory contains these two to the CMAKE_MODULE_PATH

$ export CMAKE_MODULE_PATH=“/opt/pcl_1_6/share:$CMAKE_MODULE_PATH”

By putting them in the front, that means PCL 1.6 will now get found first.

Note: when doing `export X=blah` that changes the environment variable for the current shell only.  Since I assume you want to use PCL 1.7 for most of your stuff, this would be appropriate.  If you need to always use PCL 1.6, then you would want to add these to your startup scripts, e.g. ~/.bashrc.

The implication: if you open a new terminal and try and run the executables built from the library that needs PCL 1.6, you need to issue the above `export ` commands (more specifically, after you’ve built it you will still need to get LD_LIBRARY_PATH setup again).

3. As it turns out, this is a relatively common thing to need to do in the high performance computing world (have multiple different versions of a library available).  Typically it’s so that you can change which version of MPI you are using, or switch between using libraries compiled with GCC vs Intel vs Clang etc.  If you really really really need to be able to conveniently switch between the two, you do this through “Environment Modules”.

To be clear, if you don’t know how to set this up, and can be rather painful.  For this scenario, it’s totally overkill and I do NOT recommend it just for this purpose.

In short, when using multiple different versions of a library, it is the responsibility of the user to coordinate this.  For just a one-off “I need PCL 1.6 for just one library”, just manually install it to somewhere other than /usr.  If you need many different versions of many different libraries, then you would want to invest your time into getting environment modules setup ;)

I hope that was clear enough for you to understand how to proceed, I tried very hard not to skip any details!  Good luck, post back if you’re stuck!

P.S. Note that my approach is only one way to solve this.  This domain is often personal preference, e.g. some people like to install custom builds under ~/apps or something.  You might do that if you do not have `sudo` capabilities on the machine you are building on and therefore cannot execute `sudo make install`.


On Dec 28, 2017, at 7:48 AM, rojas70 <[hidden email]> wrote:

Greetings,

Running Linux Ubuntu 14.04 with PCL 1.7.1-x. Want to run some open source
code that dates a few years back where they are using PCL 1.6.

I realize I need to install PCL 1.6 from source, but I am not so sure about
any potential conflicts that that will cause.

I guess 1.6 could be installed locally or into the filesystem... If locally,
how to get CMakeLists to detect the local version?

If installed into the filesystem, I guess:
/usr/bin files... get overwritten
/usr/include/ creates a new folder: pcl-1.6/pcl in addition to pcl-1.7/pcl
/usr/lib gets new libs for 1.6, like libpcl_xxx.so.1.6 and soft links would
have to be updated
/usr/share gets a new pcl-1.6 folder with CMake config files.

These could be used in other CMakeFiles by using the find_package(PCL 1.6
EXACT).

I would appreciate some further feedback on this.
Thanks




--
Sent from: http://www.pcl-users.org/
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users



_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Installing 2 versions of PCL in the same machine and switching between them

rojas70
Thank you for the detailed response @Stephen McDowell. Very much appreciated.



--
Sent from: http://www.pcl-users.org/
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Installing 2 versions of PCL in the same machine and switching between them

Sérgio Agostinho
In reply to this post by Stephen McDowell

Some additional observations to the very complete answer by Stephen

I doubt there are any API breaking changes between 1.6 and 1.7.  Probably just new things added / bug fixes etc.
Currently we preserve API/ABI between patch versions only i.e, from 1.6 to 1.7 you should not assume the API wasn't changed, but from 1.7 to 1.7.2 that might be the case. I wasn't around at that time to be able to tell what differences you might find between the both, but fortunately ABI Laboratory will tell you that. That page indicates "60%" compability between 1.6.0 and 1.7.0 so a lot was changed.

Technically if / when PCL 2.0 comes around, this will no longer work, but that’s likely a long way off.
Definitely not a priority in the short to mid term future.


Cheers


On 28-12-2017 18:14, Stephen McDowell wrote:
Sorry, this was wrong:

# may not need the executables in your path, this is just for completeness
$ export PATH=“/opt/pcl_1_6:$PATH”

You need /opt/pcl_1_6/bin (the extra bin) part was missing!

On Dec 28, 2017, at 10:00 AM, Stephen McDowell <[hidden email]> wrote:

Typically, /usr/{bin,lib,include} are not where you install things if you need multiple versions.  For the exact reason you show — the executables do not typically get stashed underneath their own directory.  The reason is mostly for simplicity.  If you had

/usr/bin/pcl-1.6/cloud-viewer
/usr/bin/pcl-1.7/cloud-viewer

then the user must now put something like

export PATH=“/usr/bin/pcl-1.6:$PATH”

in their startup scripts (e.g., ~/.bashrc).  On the other hand, /usr/bin is pretty much guaranteed to be in the $PATH on every unix system I’ve ever used.

!!! NOTE !!! my e-mail client is putting in UTF “curly quotes” so be careful copy-pasting, make sure you are using regular quotes in your terminal (e.g., don’t copy-paste, just type it out!)

So here are three options I would consider, definitely try (1) first because it should be the easiest:

1. It may actually be OK to use PCL 1.7 with this older library.  If they had `find_package(PCL 1.6 EXACT)` in there, it’s likely that 1.6 was the latest release at the time and that’s what they wanted to make sure users had.  E.g., there was a specific component introduced in 1.6 that was not previously unavailable.  Other users of this mailing list may know whether or not this is true, but I doubt there are any API breaking changes between 1.6 and 1.7.  Probably just new things added / bug fixes etc.

So you can modify the project you are building to try and use `find_package(PCL 1.6 REQUIRED)`.  Technically if / when PCL 2.0 comes around, this will no longer work, but that’s likely a long way off.  Changing EXACT to REQUIRED should accept 1.7 as well, the 1.6 saying “at least this version” now that REQUIRED is being used.

Side note: if it does work, it might be nice of you to submit a pull request changing EXACT to REQUIRED to the library :)

2. If it turns out that the application is not capable of building with 1.7, the “easy” way of getting this up and running is to install PCL 1.6 in a non-standard location.  With CMake, the way you would do this is something like

$ cd /path/to/repo
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/opt

This tells CMake that, instead of the default /usr/{bin,lib,include}, you want it to install to /opt.  When I do this, I typically keep all of my installations completely isolated.  So instead of /opt I might use something like /opt/pcl_1_6 so that I can delete it safely without affecting other custom installations.

So now, you would need to build PCL as normal and then execute sudo make install since /opt is protected.  Now that it is installed, you have some extra steps to make sure that you can actually use this.  This is where things become a little finessed, since presumably you want to be using PCL 1.7 for your project(s), and are only trying to use PCL 1.6 for this one project.

Note: if you are planning on linking against this other project in your own code, you have to commit to whatever version of PCL you used to compile it.  You cannot link both PCL 1.6 and PCL 1.7 in a project.

So, when you want to build this other project, you have some variables you need to setup

# may not need the executables in your path, this is just for completeness
$ export PATH=“/opt/pcl_1_6:$PATH”
$ export LD_LIBRARY_PATH=“/opt/pcl_1_6/lib:$LD_LIBRARY_PATH”

The first one makes it so the executables are available, the second one makes it so that when the linker is building the project that needs PCL 1.6, the actual library itself can be found.  When you want to run applications that linked against the PCL 1.6 libraries, LD_LIBRARY_PATH must contain the path to the PCL 1.6 libraries in order to run (assuming dynamic libraries, which is very likely).  The last one you need is to enable CMake to actually find this.  This is done using the CMAKE_MODULE_PATH environment variable.  When `find_package` is issued in a CMakeLists.txt, this variable defines where to look first, before checking the standard locations (e.g., under /usr/).  You’ll have to check the installation, it may be different on Linux, but for me on OS X it showed up under /opt/pcl_1_6/share where there were two files

- PCLConfig.cmake
- PCLConfigVersion.cmake

You want to add whatever directory contains these two to the CMAKE_MODULE_PATH

$ export CMAKE_MODULE_PATH=“/opt/pcl_1_6/share:$CMAKE_MODULE_PATH”

By putting them in the front, that means PCL 1.6 will now get found first.

Note: when doing `export X=blah` that changes the environment variable for the current shell only.  Since I assume you want to use PCL 1.7 for most of your stuff, this would be appropriate.  If you need to always use PCL 1.6, then you would want to add these to your startup scripts, e.g. ~/.bashrc.

The implication: if you open a new terminal and try and run the executables built from the library that needs PCL 1.6, you need to issue the above `export ` commands (more specifically, after you’ve built it you will still need to get LD_LIBRARY_PATH setup again).

3. As it turns out, this is a relatively common thing to need to do in the high performance computing world (have multiple different versions of a library available).  Typically it’s so that you can change which version of MPI you are using, or switch between using libraries compiled with GCC vs Intel vs Clang etc.  If you really really really need to be able to conveniently switch between the two, you do this through “Environment Modules”.

To be clear, if you don’t know how to set this up, and can be rather painful.  For this scenario, it’s totally overkill and I do NOT recommend it just for this purpose.

In short, when using multiple different versions of a library, it is the responsibility of the user to coordinate this.  For just a one-off “I need PCL 1.6 for just one library”, just manually install it to somewhere other than /usr.  If you need many different versions of many different libraries, then you would want to invest your time into getting environment modules setup ;)

I hope that was clear enough for you to understand how to proceed, I tried very hard not to skip any details!  Good luck, post back if you’re stuck!

P.S. Note that my approach is only one way to solve this.  This domain is often personal preference, e.g. some people like to install custom builds under ~/apps or something.  You might do that if you do not have `sudo` capabilities on the machine you are building on and therefore cannot execute `sudo make install`.


On Dec 28, 2017, at 7:48 AM, rojas70 <[hidden email]> wrote:

Greetings,

Running Linux Ubuntu 14.04 with PCL 1.7.1-x. Want to run some open source
code that dates a few years back where they are using PCL 1.6.

I realize I need to install PCL 1.6 from source, but I am not so sure about
any potential conflicts that that will cause.

I guess 1.6 could be installed locally or into the filesystem... If locally,
how to get CMakeLists to detect the local version?

If installed into the filesystem, I guess:
/usr/bin files... get overwritten
/usr/include/ creates a new folder: pcl-1.6/pcl in addition to pcl-1.7/pcl
/usr/lib gets new libs for 1.6, like libpcl_xxx.so.1.6 and soft links would
have to be updated
/usr/share gets a new pcl-1.6 folder with CMake config files.

These could be used in other CMakeFiles by using the find_package(PCL 1.6
EXACT).

I would appreciate some further feedback on this.
Thanks




--
Sent from: http://www.pcl-users.org/
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users




_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users