installation report on debian wheezy

Michael Richardson mcr at
Wed Sep 10 19:55:45 UTC 2014

Jeremy C. Reed <jreed at> wrote:
    >> 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?

Not really.
I simply wanted to avoid installing compilers.

I could have done make DESTDIR=/var/tmp/foo, and used tar to transfer the
results, but that doesn't always do the right thing.

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

I think it's really really broken behaviour by libtool, I think that
"make install" should never touch any files if they already exist.

    > Do you have any example of the errors you hit due to the relinking?

The .libs/*.so files are not writable by root because it's over sshfs...

    > Yes, a lot. A lot of these are dependencies of each other. I don't know
    > why has two libstdc++ headers and libssl headers.

I found that botan wasn't detected properly, so I installed libssl-dev,
which also installed zlib-dev, which then permitted libbotan to be detected...

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

It should be able to have whitespace in front of it.
I suggest treating it as a preprocessor idea... you might even want to
let cpp be the preprocessor and accept /* and // too... that is generally
fraught with issues, so maybe not...

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

In the end, it all ran, and my "media" VLAN (555) came back to life, and phones
and asterisk and Wii and netflix worked.   That vlan has the asterisk as the
dhcp server so that phones can be easily told how/where/when to boot from the
same place. 
There wasn't anything to recommend why it was better than dhcp3-server or
dhcp4-server packages, but then it's just a simply network.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr at        |   ruby on rails    [ 

More information about the kea-dev mailing list