installation report on debian wheezy
Jeremy C. Reed
jreed at isc.org
Wed Sep 10 18:03:17 UTC 2014
Michael,
Thank you much for your great feedback. I have some responses below...
On Tue, 9 Sep 2014, Michael Richardson wrote:
> I did a git checkout, git checkout -b kea-0.9 origin/kea-0.9.
> I initially ran "autoconf", but that failed, read the instructions and ran:
> autoreconf --install
Yes. You can also use the tarball for kea-0.9 and it has the generated
autoconf/automake related files included. (Note that we haven't pushed
any fixes to that git branch since it was released.)
> I needed
> apt-get install liblog4cplus-dev
> to get around:
>
> checking log4cplus/logger.h usability... no
> checking log4cplus/logger.h presence... no
> checking for log4cplus/logger.h... no
> configure: error: Missing required header files.
Yes.
> having read some things, I thought I'd install libbotan1.10-dev too.
It is optional to use OpenSSL instead if you prefer.
> It seems that "sudo make install" on results a stack of things
> being relinked again by libtool. I don't know why, they were already
> build. This is a problem if I want to build on one machine and install onto
> another machine using a (read-only) NFS/SSHFS mount.
Can you tell us some about this? Are you cross-compiling? Or using
make install with DESTDIR= setting?
It is normal behavior for libtool to relink. The first compile links the
objects with local shared libraries built direct in the build directory,
for example: /home/jreed/src/kea/src/lib/exceptions/.libs/ (libtool
creates those .libs directories) and links directly with those libraries
like ../../../../src/lib/exceptions/.libs/libkea-exceptions.so
So when installed it relinks to use prefix installed lib locations
instead, like: -L/usr/local/lib and -lkea-exceptions instead of
specific .so file.
Do you have any example of the errors you hit due to the relinking?
> In the end, I had to install a devel environment on my compiler-free target
> machine, and build there, which significantly upset me, as the set -dev
> packages I needed was large and difficult to determine.
Yes. Our guide doesn't document the package names for different vendors
but just give the "Note: Some operating systems have split their
distribution packages into a run-time and a development package. You
will need to install the development package versions, which include
header files and libraries, to build Kea from the source code."
For specific package names, we'd like users to create wiki pages about
it at http://kea.isc.org/wiki/SystemSpecificNotes
> I recommend making debian (which likely will run on Ubuntu, but not
> VV), dpkg available via a repository available for KEA if you want
> people to try it out. Since building it seems to require a bunch of
> packages (such as botan needing libbz2 to be properly detected), it
> might be worth having (in addition), a virtual package that simply
> Pre-Depends upon all the things needed to build. That way I can
> install "kea-dev-depends" as a package, and then build from git tree.
That is a good idea. We can add a ticket for that and hopefully someone
in the community can do the work.
> here is what wound up being installed (grepping for -dev packages)
> libbison-dev:i386
> libboost-dev
> libboost1.49-dev
> libbotan1.10-dev
> libbz2-dev:i386
> libc-dev-bin
> libc6-dev:i386
> libgmp-dev:i386
> libgmp3-dev
> liblog4cplus-dev
> libltdl-dev:i386
> libssl-dev
> libstdc++6-4.4-dev
> libstdc++6-4.7-dev
> linux-libc-dev:i386
> zlib1g-dev:i386
Yes, a lot. A lot of these are dependencies of each other. I don't know
why has two libstdc++ headers and libssl headers.
Our guide source did have the comment (not included in the rendered
guide):
<!--
TODO
Debian and Ubuntu:
libgmp3-dev and libbz2-dev required for botan too
-->
If I recall correctly, that is a bug in Debian's libbotan-dev package
since it should have depended on packages prodiving the headers it uses.
...
> note "pools" vs "pool". The installed example is wrong.
Yes it is a bug: http://kea.isc.org/ticket/3538
> 2) It appears that comments # are valid only in column 0. That's really
> annoying. Really really really really annoying. I understand that
> comments probably not valid JSON, period.
I agree. We should open a ticket about this non-JSON extension for
comments. Should it be shell-style where the # needs to start at
beginning of line or have whitespace in front of it?
> 3) it is not obvious what userid kea is going to run as, or if it has
> to run as root, or if there is any priveledge seperation.
No dropping privileges/changing users yet.
I will let others respond to the rest of the email.
More information about the kea-dev
mailing list