installation report on debian wheezy

Jeremy C. Reed jreed at
Wed Sep 10 18:03:17 UTC 2014


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.


> 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/

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

> 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 

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:

> 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