ldconfig missing in 'make install'
Bart van Andel
I just compiled hugin from trunk ("Pre-Release 2009.5.0.4819", libpano
also from trunk) on an up-to-date Hugin Jaunty system where it hadn't
been installed before.
bart@ubuntu-bart:~/src/hugin$ mkdir build-linux && cd build-linux
bart@ubuntu-bart:~/src/hugin$ cmake ..
bart@ubuntu-bart:~/src/hugin$ make && make install
Compiling went like a charm, installing seemed to go fine, but after
that, I couldn't start Hugin. First I tried from the menu using the
auto-generated menu item under Graphics/Hugin. No success: nothing
happened. When running it from the command line, I got this error
message:
bart@ubuntu-bart:~$ hugin
hugin: error while loading shared libraries: libhuginbase.so.0.0:
cannot open shared object file: No such file or directory
Upon inspection, this file was however found in /usr/local/lib, like
it should, I presume. A quick search using Google revealed that the
installer had forgotten about one little statement: 'ldconfig'. After
running 'sudo ldconfig' manually, I am now comfortably looking at a
nice Hugin GUI.
Could this be because I didn't do "cmake -DCMAKE_INSTALL_PREFIX=/usr/
local .." as INSTALL_cmake says I should, or is there really something
missing in the generated makefiles? I suspect the latter, because a
search for 'ldconfig' didn't yield any results:
bart@ubuntu-bart:~/src/hugin$ grep -R "ldconfig" *
(nothing)
This search includes the CMake generated files, since they are in a
subdirectory.
I'm not the first to encounter this exact same issue, Bruno and others
have helped out someone else before in a 2 year old thread [0]. Might
be a CMake issue [1]. My version:
bart@ubuntu-bart:~/src/hugin$ cmake --version
cmake version 2.6-patch 2
So, do we need a patch (not sure how to include this in the CMake
process), or just instruct to run 'sudo ldconfig' manually?
[0] http://groups.google.com/group/hugin-ptx/browse_thread/thread/e67e1d5a6215b951/84ae92aaf75acdd0
[1] http://www.google.nl/search?q=cmake+ldconfig
--
Bart
Kornel Benko
> So, do we need a patch (not sure how to include this in the CMake
> process), or just instruct to run 'sudo ldconfig' manually?
>
You may want to consider this:
cmake .. -DCPACK_BINARY_DEB:BOOL=on
make package
and install the created .deb package instead.
Kornel
--
Kornel Benko
Kornel...@berlin.de
Bart van Andel
> You may want to consider this:
> cmake .. -DCPACK_BINARY_DEB:BOOL=on
> make package
>
> and install the created .deb package instead.
Okay, just did that (5 archives get created, I'm sure this can be
suppressed using additional options), and although it errors on
installation, Hugin works afterwards:
bart@ubuntu-bart:~/src/hugin/build-linux$ sudo dpkg -i
hugin-2009.5.0-Linux.deb
(Reading database ... 233422 files and directories currently
installed.)
Preparing to replace hugin 2009.5.0 (using hugin-2009.5.0-
Linux.deb) ...
Unpacking replacement hugin ...
dpkg: dependency problems prevent configuration of hugin:
hugin depends on libpano13 (>= 2.9.15); however:
Package libpano13 is not installed.
dpkg: error processing hugin (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
hugin
Note that I have installed libpano13 using the regular 'make install',
which would explain the error. Apparently this can safely be ignored,
since Hugin works fine.
Why would this 'make package' be the better solution, whereas 'make
install' is normally the way to go? Except for the missing 'ldconfig'
my previous attempt worked fine, quicker (no compressing/decompressing
needed), needed less command line work and didn't give a (ignorable)
error. I'm curious?
--
Bart
Kornel Benko
> > You may want to consider this:
> > cmake .. -DCPACK_BINARY_DEB:BOOL=on
> > make package
> >
> > and install the created .deb package instead.
>
> Okay, just did that (5 archives get created, I'm sure this can be
> suppressed using additional options), and although it errors on
> installation, Hugin works afterwards:
Yes, you can suppress it. (e.g. -DCPACK_BINARY_TGZ:BOOL=OFF). Look into the file CMakeCache.txt
> bart@ubuntu-bart:~/src/hugin/build-linux$ sudo dpkg -i
> hugin-2009.5.0-Linux.deb
> (Reading database ... 233422 files and directories currently
> installed.)
> Preparing to replace hugin 2009.5.0 (using hugin-2009.5.0-
> Linux.deb) ...
> Unpacking replacement hugin ...
> dpkg: dependency problems prevent configuration of hugin:
> hugin depends on libpano13 (>= 2.9.15); however:
> Package libpano13 is not installed.
> dpkg: error processing hugin (--install):
> dependency problems - leaving unconfigured
> Processing triggers for man-db ...
> Errors were encountered while processing:
> hugin
>
> Note that I have installed libpano13 using the regular 'make install',
> which would explain the error. Apparently this can safely be ignored,
> since Hugin works fine.
No, you have not. At least not as a .deb package. You may want to install this package the same way, as hugin.
(cmake [your values]; make package;)
> Why would this 'make package' be the better solution, whereas 'make
> install' is normally the way to go? Except for the missing 'ldconfig'
> my previous attempt worked fine, quicker (no compressing/decompressing
> needed), needed less command line work and didn't give a (ignorable)
> error. I'm curious?
Because using the package-manager may have some advantages?
> --
> Bart
bruno.postle
>
> Upon inspection, this file was however found in /usr/local/lib, like
> it should, I presume. A quick search using Google revealed that the
> installer had forgotten about one little statement: 'ldconfig'. After
> running 'sudo ldconfig' manually, I am now comfortably looking at a
> nice Hugin GUI.
The problem is that `make install` needs to work for non-root users,
this is why ldconfig is usually run after installation.
--
Bruno
Bart van Andel
> Am Friday 18 December 2009 schrieb Bart van Andel:
>
> > On 18 dec, 12:22, Kornel Benko <Kornel.Be...@berlin.de> wrote:
> > > You may want to consider this:
> > > cmake .. -DCPACK_BINARY_DEB:BOOL=on
> > > make package
>
> > > and install the created .deb package instead.
>
> > Okay, just did that (5 archives get created, I'm sure this can be
> > suppressed using additional options), and although it errors on
> > installation, Hugin works afterwards:
>
> Yes, you can suppress it. (e.g. -DCPACK_BINARY_TGZ:BOOL=OFF). Look into the file CMakeCache.txt
Ok. Why does the 'make package' default to building *all* packages,
instead of just one? Not all package formats seem equally relevant to
me, at least (.tar.Z and .sh aren't used that often, are they?) Is
the .sh output the most portable file? In that case 'make package'
could default to only building that file? I know VirtualBox uses a
similar approach for its VirtualBox Additions (the .run files are
built with Makeself).
> > Note that I have installed libpano13 using the regular 'make install',
> > which would explain the error. Apparently this can safely be ignored,
> > since Hugin works fine.
>
> No, you have not. At least not as a .deb package. You may want to install this package the same way, as hugin.
> (cmake [your values]; make package;)
Like I said: I did a 'make install', not a 'make package'. I already
assumed that a 'make package' there would resolve the error.
> > Why would this 'make package' be the better solution, whereas 'make
> > install' is normally the way to go? Except for the missing 'ldconfig'
> > my previous attempt worked fine, quicker (no compressing/decompressing
> > needed), needed less command line work and didn't give a (ignorable)
> > error. I'm curious?
>
> Because using the package-manager may have some advantages?
Ok. I see now that the wiki refers to your suggested approach too [0],
but the INSTALL_cmake file probably needs an update. When downloading
a source package, the INSTALL* would be the first file (for me) to
look for building instructions.
Thanks for helping out. Forgive me my ignorance, I'm not exactly your
Linux hero, but I like wandering around :)
[0] http://wiki.panotools.org/Hugin_Compiling_Ubuntu
--
Bart
Bart van Andel
> this is why ldconfig is usually run after installation.
Really? I could only run the command using 'sudo make install', and I
haven't seen many packages for which 'make install' works without the
'sudo'. At least in my Ubuntu installation normal users don't have
write access to /usr/local/lib or /usr/local/bin, and I haven't
tempered with the rights.
--
Bart
bruno.postle
> > The problem is that `make install` needs to work for non-root users,
> > this is why ldconfig is usually run after installation.
>
> Really? I could only run the command using 'sudo make install', and I
> haven't seen many packages for which 'make install' works without the
> 'sudo'.
Try this with any other source package, you don't need to be root to
run:
make install DESTDIR=/tmp/foo
This isn't just academic, every package on your Linux system was built
exactly like this with non-root user accounts.
--
Bruno
Kornel Benko
> >
> > Yes, you can suppress it. (e.g. -DCPACK_BINARY_TGZ:BOOL=OFF). Look into the file CMakeCache.txt
>
> Ok. Why does the 'make package' default to building *all* packages,
> instead of just one? Not all package formats seem equally relevant to
> me, at least (.tar.Z and .sh aren't used that often, are they?) Is
> the .sh output the most portable file? In that case 'make package'
> could default to only building that file? I know VirtualBox uses a
> similar approach for its VirtualBox Additions (the .run files are
> built with Makeself).
We stick here with the CPack-module (part of cmake). I don't like it either.
Bart van Andel
> run:
>
> make install DESTDIR=/tmp/foo
>
> This isn't just academic, every package on your Linux system was built
> exactly like this with non-root user accounts.
Ah! Interesting, thanks! Summarizing, we now have three approaches
here:
0. Create build folder (all; not really necessary but prevents
cluttering the source folders):
mkdir build
cd build
1. Use root privileges to install directly from binaries, into default
location (/usr/local/):
cmake ..
make
sudo make install
sudo ldconfig
2. Use root privileges to install from package (in this case, a Debian/
Ubuntu package):
cmake .. -DCPACK_BINARY_DEB:BOOL=on
make
make package
sudo dpkg -i hugin-*.deb
3. Use normal user privileges to install in user directory
cmake ..
make
make install DESTDIR=/some/non-root/dir
Did I still miss anything (install from package into custom non-root
directory maybe)?
Thanks Kornel and Bruno!
--
Bart
bruno.postle
> Ah! Interesting, thanks! Summarizing, we now have three approaches
> here:
I create a tarball with `make package_source` then package this into
an RPM using a .spec file (I don't use the cpack RPM stuff).
I also have a /usr/local/share/hugin symlink which points to the SVN
src/hugin1/hugin folder, this allows me to build and test the GUI
without going through the `make install` cycle. This doesn't work for
everyday use, e.g. the command-line tools are not in my $PATH, but it
is ok for checking bug reports and patches.
--
Bruno