ardour 2.8.11 / debian 5: major build problems

Hello everyone,

I have tried to build ardour 2.8.11 from source on Debian 5, but I have encountered some serious problems.

My original plan was to create and contribute an integrated package that installs into /usr/local/ardour on Debian 5 i386/amd64.

I use the following source packages:

I had built ardour before (actually, there is a thread somewhere in this forum with a description of how I had done that build), but the problems seem to have worsened.

The first problem is that GTK+ does not compile anymore, because it complains about a missing gdk-pixbuf library. Unfortunately, there does not seem to be a source code package of such a library, and installing the Debian pixbuf/pixbuf-devel stuff (newest version) does not help either (undefined references when linking).
Well, I have never ever seen a GTK+ build run smoothly, but now it seems to be completely broken.

Anyway, since my Debian system has some version of GTK+ installed, I would have attempted to skip the GTK+ stuff, since everything else seems to be installed by now. Unfortunately, the SCons build system breaks everything else: library paths, include paths, target directory, and I don’t know what else…

There seems to be no possibility to tell SCons where to look for libraries and include files - everything is in /usr/local/ardour (./lib, ./include, ./share, …).

I wonder whether there is any description or guide on how to build ardour, including all its dependencies, and on how to use this epic mess of build system called SCons?

How exactly do the ardour developers create a test build of ardour on their machines? Where do you get libgdk-pixbuf from? What environment variables need to be set? How does SCons need to be modified so it respects environment variables like LD_LIBRARY_PATH, CFLAGS and so on?
Or does every developer just install every single file of the newest 4+ GB Ubuntu nightly build, and then hope that all dependencies are already resolved?

Hello again,

the current status is that everything is compiled now, except for ardour itself.

I got a new gdk-pixbuf package by following links to GTK+ 3 source (recently released), and then navigating through the webserver’s directory tree. I was finally able to compile GTK by modifying the system by means of wrapper scripts and symlinks, so GTK thinks everything is in /usr when it actually is in /usr/local/ardour.

The only remaining problem is that ardour does not compile, because scons environment ‘feature’ makes it impossible to compile anything when the libraries and headers are not in the system-global directories (that is, somewhere else than /usr/include and /lib or /usr/lib).

Obviously, as everything is in /usr/local/ardour, scons needs to specify the header and library paths to the C compiler, so the C compiler will find the correct files. This is very easy with make/dmake/gmake or whatever, by simply defining CFLAGS, LDFLAGS, LD_LIBRARY_PATH and so on, however it seems to be impossible with scons, because scons ignores that. I tried modifying the SConstruct script to add these environment variables back, but it didn’t work - I probably did something wrong; no wonder, as I have to admit that I have virtually no insight into a 1400+ lines build script.
That’s why I don’t like scons, I think it is the opposite of the unix philosophy.

Maybe someone who has a comprehensive understanding of scons could give a hint on how to configure scons, so it would tell the C compiler where the libraries are.

Everything is in /usr/local/ardour, that means, headers are in /usr/local/ardour/include, libraries are in /usr/local/ardour/lib (all packages where compiled and installed with --prefix=/usr/local/ardour).
The build environment that worked for all the packages, except for scons/ardour, was:
export CFLAGS="-fPIC -I/usr/local/ardour/include -L/usr/local/ardour/lib"
export CXXFLAGS="-fPIC -I/usr/local/ardour/include -L/usr/local/ardour/lib"
export PATH="/usr/local/ardour/bin:${PATH}"
export LD_LIBRARY_PATH="/usr/local/ardour/lib"
export LD_RUN_PATH="/usr/local/ardour/lib"
export PKG_CONFIG_PATH="/usr/local/ardour/lib/pkgconfig"

Thanks for reading, and thanks in advance for your comments on this issue, if any.

@graphbobby: you are making a series of major mistakes in your use of SCons and the way you’ve built GTK. We (or certainly I) will not support people who abuse what is a perfectly functioning build system without understanding how it actually works. I don’t mean to be so harsh, but there are so many errors in the post you’ve just added that I don’t even want to try correct what you did. The SCons system we provided will build a working version of Ardour on almost any Linux (or even OS X) system. I have no idea why you felt it necessary to try to tweak it so much, but the fact that you did says more about the non-standard nature of your system than anything else.

Unfortunately, there does not seem to be a build of ardour2 for debian, at least not in debian stable (search in package directory for "ardour" or "ardour2" says "Sorry, your search gave no results").
No there is no ardour in the Debian Lenny repos. But i used to compile it for Lenny without any problem.

Else it’s available in the new Debian stable 6.0 squeeze.

If you want to stick to Lenny maybe you can try to add these repos :

deb lenny-backports main

After ardour 2.8 should be available. If it’s not too late for your system.

Hello paul and youki,

thank you for your quick replies.

Yes, it is a non-standard configuration; there are multiple versions of the same libraries on the system in different locations (intentionally). However, I was not aware that this is a problem for GTK and/or scons, because it has never been a problem with other unix software/utilities, so I expected it to work. All the other packages compiled and installed properly with exactly the same settings.

Youki: Thanks for the hint, I might try the new Debian release, I’m interested in what’s new anyway.
The system is still ok. My intention was to create a build that does not change the base system, that’s why I install into /usr/local/ardour and not into /usr/bin, /usr/lib, and so on.

@graphbobby: i’ll try to explain it really, really quickly: we try to use pkg-config to discover the location of any packages that we believe supply them. otherwise we use the other builtin scons mechanisms to look for libraries and headers. as i mentioned earlier, scons was intentionally written to ignore the user’s environment. this is a design decision you are free to take up with the scons people. we no longer use scons for ardour3 (though this is not the reason for the change) and so we are not interested in discussing its behaviour. we did make scons in our case specifically import a few environment variables that seem required to work around some stupidities with pkg-config and friends (e.g. a system install of pkg-config does not look in /usr/local/lib/pkg-config by default). we also import PATH, CC. CXX and DISTCC_HOSTS (these were environment variables that the developers themselves require, that’s all). no other part of your environment will have impact on the operation of scons. feel free to take up your issues with scons with the scons team if you think it is worthwhile - ardour2 is feature frozen at this time, and it is extremely unlikely that we will make any modifications to the build system that are sufficient to make it work on a system such as the one you have set up.

you mentioned trying to find gdk-pixbuf via the GTK3 website - this is a disaster in the making unless you actually navigated out of the gtk3 tree and back into the gtk2 one.

@graphbobby: Regarding gdk-pixbuf - did you miss my answer #7 ?

Regarding scons and env variables - see if 2.1 on is of any help

hello, and thank you again for your replies.

paul, thank you for your comment on scons, I did not mean to blame the ardour developers for any headache scons might have caused; I just wanted to note that it seemed to be the source of some problems in my specific case. I would also like to note that I certainly do not expect anyone to make changes to ardour or to scons to make my - concededly non-standard - build work.

As for gdk-pixbuf: yes, I followed a link on the GTK+ 3 page, but then navigated to the last stable release of gdk-pixbuf for GTK+ 2. The GTK+ issue seems to be solved, it compiled yesterday, I didn’t test yet, but I guess it works by now.

peder: I did read your answer #7 - the problem is solved already :slight_smile:
thanks for the scons link as well, and thanks for your help!

I’ve built Ardour packages for every version of Ubuntu since 8.10, and have never had this issue. As Ubuntu, (and hence, Debian) ship with a version of Ardour (though it may not be up to date), just do “sudo apt-get build-dep ardour2”, and you’ll recieve all the *-dev packages needed for building Ardour.

Good Luck

@graphbobby: I’m afraid that your problems have nothing to do with SCons whatsoever. SCons uses pkg-config to locate almost all necessary libraries, so as long as the pkg-config files exist in the standard location(s) or along PKG_CONFIG_PATH, SCons will find them. This is how almost all modern *nix software libraries are used in builds of dependent software.

As for gdk-pixbuf, you seem unaware that this was split out of the main GTK tree quite some time ago. I humbly and respectfully suggest that when things are broken when you try to build a piece of software that is regularly and constantly rebuilt on almost every Linux distribution you can think of, that you consider the possibility that the issue is your build environment rather than our build system.

Happy to help answer further, specific questions.

@graphbobby : The standard build description for Ardour on Debian (or at least Ubuntu) is to first run ‘sudo apt-get build-dep ardour2’, like macinnisrr said, to get all the necessary devel packages and then run ‘scons && scons install’ in the untarred ardour directory. Just as simple as that.
I personally run ‘mkdir /opt/ardour-2.8.11 && scons PREFIX=/opt/ardour-2.8.11 LV=1 && scons install’ to install to /opt/ardour-2.8.11 instead of /usr/local and include LV2 support (assuming I have ran ‘apt-get install libslv2-dev’ first). ‘scons -h’ will show you other possible flags to use.

'pkg-config --modversion --libs ’ will show you which version, name and optional linker path for a lib your system has found and is using. On my openSUSE it shows “2.24.1 -lglib-2.0” for glib-2.0 for instance.

There’s also some confusion in your build description: you say there’s no source for gdk-pixbuf and yet you list gdk-pixbuf_2.23.0-2.debian.tar.gz and gdk-pixbuf_2.23.0.orig.tar.gz. But to be able to compile it you need to have glib2 compiled first (and possibly other stuff as well), assuming you want to go through the road of doing everything yourself.

Thank you for your replies.

Unfortunately, there does not seem to be a build of ardour2 for debian, at least not in debian stable (search in package directory for “ardour” or “ardour2” says “Sorry, your search gave no results”).
Ubuntu has a binary distribution of ardour in its repository.

With SCons, the problem seems to be that it does not pass environment variables properly.
I had built ardour before, in May 2009 (see, and I also had encountered problems with librdf, xrender and GTK+ (of course and as always, sigh), and then with SCons and pkg-config. In 2009, I had fixed the SCons/pkg-config problem by writing a wrapper shellscript around pkg-config.
The problem in librdf is still not fixed, by the way.

I got the gdk-pixbuf packages from debian’s servers, however there does not seem to be a download page on,, etc. and there is virtually no documentation on how to build the neccessary GDK code before building GTK+. Not ardour’s fault of course.
Trying to build GTK+ after having built glib, atk, cairo, pango and gdk-pixbuf fails with unresolved references to gdk-pixbuf. Actually, I had expected the GTK+ build to fail, there is always something wrong with it, and I’m pretty sure that it has nothing to do with my build environment, since much bigger and more complex stuff like Qt commonly compiles without a problem. It seems that GTK+ is simply messily implemented.

I can’t remember the precise SCons error message now. But I will try again and post a more specific description of what goes wrong during the build. If everything finally compiles, I will provide a complete walk-through on how to compile all these packages.

As far as I can see, Ardour is not in Debian Lenny or earlier, but Ardour 2.8.11 is in Debian testing which by some accounts is ripe for release soon (whatever “soon” means in the Debian release timing world)
so it seems to be a recently introduced package.

IMHO the best way to run Ardour in Debian is to install AVLinux. Works for me :slight_smile:

@graphbobby: scons’ handling of environment variables is not a mistake - its a design feature of the program. Its intended to give a stable, precise build regardless of the environment of the person building it. We explicilty make it pay attention to some specific variables (notably PKG_CONFIG_PATH),. but this is not an “error” by SCons (though you are free to disagree with it).

I don’t agree with your criticisms of the GTK build system either, but then again, its been 12 years since I first did that so maybe I’ve forgotten the hassle when you try it the first time. I do this build regularly on many different systems, and never run into problems.

I really do think that you should follow anhata’s advice: if this build stuff is confusing or maddening to you, then stop, because it really doesn’t need to be, and the problems are not related to Ardour itself. There’s really no good reason to be going through this kind of pain just to use Ardour.

@graphbobby: The first hit on Google for “gdk-pixbuf source” points to and the latest verion is 2.23 (Dec 23 2010).
It uses the standard ‘./configure ; make ; make install’ procedure all autoconf packages use, and I’m pretty sure all GTK-related software uses it.

What were the exact gtk+/gdk-pixbuf errors?
Googling for “gtk+ dependencies gdk-pixbuf” pointed to this ( where it has a special notice about gdk-pixbuf. But that concerns gtk±2.20.1 so it might be fixed in your version.