Search:

Newer kernels have moved version.h from include/linux. You can link it,

sudo ln -s /usr/src/linux-headers-`uname -r`/include/generated/uapi/linux/version.h /usr/src/linux-headers-`uname...

probably something like

$ sudo apt-get install gnome-doc-utils
then regenerate the macros to get GNOME_DOC

$ autoreconf -fi
$ ./configure
might work

Ah, this is what I was thinking of
http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/VPATH-Builds.html

Certainly I'm no expert on autotools but I don't think they work that way, in the sense of having objects and binaries sent to separate directories. Think of it more in terms of having a source tree...

Have a look at

$ apt-mark auto <package>or older apts use

$ apt-get markauto <package>Might be what you're looking for

+1 for this, use a virtual machine for this if possible though, if you've got a reasonably new machine it can be perfect for testing out toolchains

You're missing a dependency, apt-file search <something.h> is often good for these, in this case its


$ sudo apt-get install zlib1g-dev

This works for building Summon on 64bit Ubuntu 12.04

* Download Summon http://sourceforge.net/projects/summon/files/latest/download?source=files
* Download Ramp (in TPP)...

I'll put together a howto later, thats probably simpler, see how you get on with that

Your last error looks like the path to RAMP isnt set properly, heres a diff of my working Makefile

--- Makefile 2008-02-11 11:27:39.000000000 +0000
+++...

Just to be clear, the suggestion I made works on 12.04, with a few header updates (<cstdlib> and <cstring> may need added in a few files). The binary appears to work but then I haven't tested it to...

My guess is that base64 has now been renamed ramp_base64, try renaming tose references in Summon's Makefile

The chances that the compiler is faulty is usually tiny compared to the probability that your code is not doing what you expect it is. when one compiler skips something and another doesn't I'd tend...

I'd have thought it was but anyway, if it exists anywhere in the source tree then


$ find ./ -name '*.rej'

When you see this in a configure stage

configure: error: No package 'dbus-1' found.

it usually means you're missing the development package (those ending with -dev)
in this case

$ apt-cache...

And you may or may not want 'backtrace full' too

-g and -O0 are the options to g++ you'll want to try

The object files need to come before the linker libraries, probably change the Makefile


opengazer: $(objects)
g++ $(CPPFLAGS) -o $@ `pkg-config cairomm-1.0 opencv gtkmm-2.4 --libs` $(LINKER)...

Seems that this is configuring itself to look for libraries in lib64/ if it finds itself on x86-64, hence the linking issue. You can change it with...

# libsubdir is setup in m4 scripts
$ grep -r...

This isnt giving up, it looks fine (apart from inevitable warnings) and I imagine its built the source package ok. if you look in directory above do you not find tarball and .dsc files?
-S will...

Unless you've got your heart set on compiling everything from source I'd recommend instead that you look into apt-offline. It'll generate the needed package list, including dependencies, on your...

Personally I would have thought it's a packaging thing, it's a thing relating to integration into a distribution, rather than intrinsic to the software itself. I've no idea if theres a policy on it,...

I think this is a problem to do with
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
which is 'in progress' to be fixed I imagine
You could compile -static I suppose for the...

Are you building a debian package with

$ debuild -b -us -uc
If you're compiling a straight build from source (no packaging) then you'll need to look at debian/rules to see what options debian...

This automatic method of assigning a version from git is failing leaving a blank version in the generated changelog, which causes the debuild to fail
Autobuild/debian.sh:
VER=`git describe | sed...