where make install puts things

[johnfi...@gmail.com]

I am building a fork of hugin

https://sourceforge.net/projects/huginplusplus/

That requires a fork of libpano13

https://sourceforge.net/projects/fastptoptimizer/

I don't think my issues are specific to those forks.  Likely this is just my ignorance regarding CMake.

Are there options I should have used with CMake to get things to go to the right place?  Or is the place they went "right" and I should have done something different with the other CMake to find things in that place.

When I did a make install on the fork of libpano13, it put files in /usr/local/lib64

But the Fedora package for libpano13-devel puts those files in /usr/lib64

The build for the fork of hugin finds the files where libpano13-devel put them.

I would like to know the generally correct way to have make install put things in the right place.

But I would also like to know how to keep such things more separated:

Can the build for hugin be made to find the fork of libpano13 where that was built (so I don't install that at all)?  If not, can I install it elsewhere so it is entirely non overlapping with the fedora libpano13-devel, and get the build of the fork of hugin to use that?  (currently most files of the make install go to the same places as  libpano13-develputs them, but some go to different places).

[Florian Königstein]

I have limited knowledge in Linux, so I cannot say much about that.

Did you take fastPTOptimizer from

https://sourceforge.net/projects/fastptoptimizer/files/libpano13-2021-06-07.zip/download

or from the Mercurial repository that I have just generated by forking the current version of libpano13 and merging my changes into it ?

https://sourceforge.net/p/fastptoptimizer/code/ci/default/tree/

When taking a snapshot from the Mercurial repo, it should install in the same directory as libpano13 since I didn't change the directories in the CMakeLists.txt file.

Maybe there's a way in the Linux build system to build it only in the directory where the source code has been unzipped (no install in /usr/... ).

Then you could have separate places for the build files for fastPTOptimizer and libpano13.

If you run the GUI for CMake, you can manually enter the paths where the libraries are if CMake doesn't find it automatically or finds it in a wrong place.

[johnfi...@gmail.com]

On Thursday, March 3, 2022 at 1:42:25 PM UTC-5 Florian Königstein wrote:

I have limited knowledge in Linux, so I cannot say much about that.

Did you take fastPTOptimizer from

https://sourceforge.net/projects/fastptoptimizer/files/libpano13-2021-06-07.zip/download

No.

or from the Mercurial repository that I have just generated by forking the current version of libpano13 and merging my changes into it ?

https://sourceforge.net/p/fastptoptimizer/code/ci/default/tree/

Yes.

In SourceTree on Windows, I cloned that repository into a directory on a share exported by that Windows system.

On Fedora, I created a build directory (outside that windows share) and in the build directory ran CMake giving it only the path to the source code in the Windows share (no other options).  Then:

make -j32

sudo make install

When taking a snapshot from the Mercurial repo, it should install in the same directory as libpano13 since I didn't change the directories in the CMakeLists.txt file.

Right.  I asked here, rather than just asking you, because I am confident the issue is not specific to anything you did.  It is something I failed to do, which would be equally required if I had built libpano13 from source code rather than installing the official Fedora package.

 

Maybe there's a way in the Linux build system to build it only in the directory where the source code has been unzipped (no install in /usr/... ).

Then you could have separate places for the build files for fastPTOptimizer and libpano13.

I get that if I simply make without make install.   The hard part is whether/how the build of hugin can find/use the build of (the fork of) libpano13 if it is not installed.

If you run the GUI for CMake, you can manually enter the paths where the libraries are if CMake doesn't find it automatically or finds it in a wrong place.

I haven't figured out how to run that GUI on Linux (or even if it is possible).  Using that GUI on Windows, I specified where to find things when trying to build Hugin and its dependencies and never figured out how to accomplish anything that way.  Editing the CMakeCache.txt file was the only way I ever was able to influence where CMake found things on Windows when building dependencies of hugin.  For hugin itself, that method did not work, and I never got CMake to find things.

Editing that file on Fedora is on my TODO list for kludging past this problem.  But I'm working on many projects at once and did not get to trying that yet.  I'd rather know the "right" way.

[Bruno Postle]

On Thu, 3 Mar 2022, 17:36 johnfine wrote:

Are there options I should have used with CMake to get things to go to the right place?  Or is the place they went "right" and I should have done something different with the other CMake to find things in that place.

When I did a make install on the fork of libpano13, it put files in /usr/local/lib64

But the Fedora package for libpano13-devel puts those files in /usr/lib64

The build for the fork of hugin finds the files where libpano13-devel put them.

It is normal for software that you have compiled yourself to be installed into /usr/local. This way you don't overwrite files installed by the distribution package manager in /usr - i.e. installing into /usr can make a big mess that isn't easy to clear up.

The libpano13-devel rpm package only exists for you to compile and link to the libpano13 rpm package in /usr. Just uninstall it and your Hugin build will pick up your forked libpano13 headers in /usr/local/include

You may also need to set LD_LIBRARY_PATH for your forked Hugin to use this library at runtime.

-- 

Bruno

[johnfi...@gmail.com]

On Thursday, March 3, 2022 at 3:11:34 PM UTC-5 bruno...@gmail.com wrote:

The libpano13-devel rpm package only exists for you to compile and link to the libpano13 rpm package in /usr. Just uninstall it and your Hugin build will pick up your forked libpano13 headers in /usr/local/include

Thanks.  I asked for the "right" way to do this.  Your answer sounds like that.  I haven't tested your answer and it doesn't really fit what I'm trying to do.  But it does help me understand how things fit together.  I want to build both the fork and non fork version of hugin, so I should be using both versions of libpano13.

The kludge that worked was:

I repaired the install of the non fork version:

sudo dnf reinstall libpano13-devel

I edited  CMakeCache.txt in my build directory for the fork of libpano13 so that it would install entirely disjoint from the -devel package (rather than partially overlapped).  I changed

CMAKE_INSTALL_PREFIX:PATH=/usr

to

CMAKE_INSTALL_PREFIX:PATH=/ELSEWHERE

I reran:

cmake /media/windows/repository_for_pano_fork

make -j32

sudo make install

Then I switched to the build directory for the hugin fork and edited its CMakeCache.txt, finding all (5) places that referenced pano13 (case insensitive) and in each changed /usr to /ELSEWHERE

Then reran

cmake /media/windows/repository_for_hugin_fork

make -j32

(I did not install it)

That is clearly a kludge.  But it works and it is what I understand enough to do.

You may also need to set LD_LIBRARY_PATH for your forked Hugin to use this library at runtime.

I have forgotten what I long ago understood about when an executable keeps the reference to the .so file it was linked against vs. when it searches again for that .so at load time.  If I ever make a package for the fork of hugin, I'll need to understand that stuff.  But I do remember how to use ldd.  The hugin executable works without LD_LIBRARY_PATH, because it is tied to the location of the .so file that it was linked against  /ELSEWHERE/lib64/libpano.so.3

I also needed the usual adjustment to the XRC location in order to be able to run this hugin without installing it.

More testing required.  But so far, that seems like all I needed to do to connect the fork of libpano13 to the fork of hugin without overwriting anything needed by the non fork version of hugin.

Red parts are not literally the names I used, but communicate the idea better than the actual names.  The rest (including the fact that my source code is in repositories on a windows system) is literal.

[Gunter Königsmann]

That should be the right way to do it. Except that editing Cmakelists.txt can be avoided if during configuration cmake is called with the -DCMAKE_INSTALL_PREFIX=path switch...