User: Password:
|
|
Subscribe / Log in / New account

It's just not that simple to build userspace binaries that use lots of libraries

It's just not that simple to build userspace binaries that use lots of libraries

Posted Mar 24, 2010 8:45 UTC (Wed) by ringerc (subscriber, #3071)
In reply to: KVM, QEMU, and kernel project management by mingo
Parent article: KVM, QEMU, and kernel project management

That is a plain user-space tool that lives in the kernel repository. It can be built and installed in user-space by doing:

  cd tools/perf/
  make -j install

That's exactly what they can't do, because building real world GUI-using userspace binaries isn't that simple. You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries apps like qemu need to link to to achieve the functionality people expect of them. The day I see a makefile.am and configure.in or a CMakeLists.txt in the kernel tree ...

Look at the output of: ldd `which kvm` to get an idea of the variety of things the kvm executable tends to link to. Now think about hand-writing Makefile rules that work on a reasonable variety of Linux systems (let alone the BSDs, OpenSolaris, and other free platforms) that'll have a reasonable chance of locating and correctly using those libraries. No chance.

To be able to keep the core kvm userspace code in the kernel tree, they'd probably have to rip up kvm into a core libkvm.so and "the rest". libkvm.so would be usable by an extremely stripped down GUI-less sound-less ....-less kvm-basic that could also be built by simple makefile and stored in the kernel tree. It'd also be used by a full-featured kvm maintained elsewhere and built with regular build tools. It doesn't seem like any improvement to me, it just moves the interface boundary a bit.

I (as joe random) happen to share your general sentiment that some userspace really could use being kept in the kernel. udev or whatever device management daemon of the day is used; module-init-tools; etc. I just don't think it's realistic to put kvm in that group unless it does prove useful to move the interface boundary into a user-space library, ie stable library ABI for library shipped with kernel, unstable kernel ABI for talking to that library. And good luck getting that past the stable-kernel-ABI dragons.


(Log in to post comments)

It's just not that simple to build userspace binaries that use lots of libraries

Posted Mar 25, 2010 12:39 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries...

These days most popular libraries support pkg-config which makes this a whole lot simpler.

It's just not that simple to build userspace binaries that use lots of libraries

Posted Mar 26, 2010 3:32 UTC (Fri) by ringerc (subscriber, #3071) [Link]

True, and pkg-config has come a long way lately with things like variable support and even msvc syntax handling. It doesn't help very much if you need to test for build options, though there's no reason why it *can't*. pkg-config's --variable feature would let you do build option tests ... but far too many packages fail to set appropriate .pc variables for important build options.

At least pkg-config makes version tests, cflags discovery, etc a whole lot easier.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds