Mac OS X Native Build from Source version questions.

Ok, for a variety of reasons I’m attempting a from source build on Mac OS X Snow Leopard, as mostly documented at

Yes, I really want to do this, but I have a few specific questions regarding versions, a clarification on buildsystems, and some miscellany. Note that it is not my intention to release any binary builds, just build them for myself (I already did the donation, subscription, and ‘buy Mixbus’ things…); Paul needs to eat, ya’know!

The biggest reason is so that I can customize the code to use more of the TASCAM US-428 capabilities (I want to do things like track selection via the aux buttons, change mappings based on button selections, and in general get the full use of the US-428’s control surface which I don’t think is possible through the stock General MIDI controls). My intent is to release the source contributions back to the project as a ‘US-428/224’ patch of sorts (and I want to use that same thing on Linux, but the US-428 driver on Linux isn’t nearly as full-featured as the OS X one). A more general macro-language to define MMC actions and do logic by MMC is I guess the ultimate goal, then anyone could write a ‘MIDI/MMC’ macro set for any specific surface to gain much use of that surface. Just a thought…

A second reason is to track the 2.0-ongoing branch in the ardour SVN on OS X.

Thirdly, if I’m going to go to the effort of doing OS X at all, I want to DO OS X, not just use it… the Linux geek in me shows through…

In any case, the questions:
1.) What specific versions of the gtk-osx stuff are used for the ‘official’ build? A listing of ~/gtk/source would suffice. Here’s what I have from last night in my ~/gtk/source:

XML-Parser-2.36 XML-Simple-2.18 atk-1.28.0 autoconf-2.63
automake-1.10.1 automake-1.4-p6 automake-1.7.9 automake-1.8.5
automake-1.9.6 cairo-1.8.8 expat-2.0.1 fontconfig-2.7.3
freetype-2.3.11 gettext-0.17 glib-2.22.2 gnome-common-2.28.0
gnome-doc-utils-0.10.13-fake2 gtk±2.18.2 gtk-doc-1.11
gtk-osx-docbook-1.0 hicolor-icon-theme-0.11
ige-mac-integration-0.8.6 intltool-0.40.6 jpeg-7
libpng-1.2.40 libtool-2.2.6 m4-1.4.11 pango-1.24.5
pixman-0.16.0 pkg-config-0.23 pkgs tiff-3.9.1

2.) What specific version of gtk+ is the gtk patch for (I know the specific revision is 20839, but it seems the gtk+ project has changed revision control systems recently, and while I know how to get specific revisions with subversion, git is a whole different story)?

3.) Paul wrote a post for the Imendio developer forum about packaging Ardour, but it’s empty (GTK-OSX isn’t at Imendio anymore, but on sourceforge…). Anyone have an archive of that post?

4.) How in the world is a macports installed scons supposed to work with a GTK-OSX jhbuild-using application when the GTK-OSX developers are adamant about macports/fink not being in $PATH when using jhbuild ( which states “If you have MacPorts or Fink installed, be sure to remove their paths from $PATH, $DYLD_LIBRARY_PATH, $PKG_CONFIG_PATH and any build-related environment variables ($CFLAGS, $LDFLAGS, etc.) before you try to run jhbuild. Mixing Fink/MacPorts and GTK-OSX will fail.”)? And since to build Ardour you need the macports scons and the GTK-OSX jhbuild shell both at the same time… I guess just looking for clarification if just making sure the GTK-OSX jhbuild and the necessary bits for GTK-OSX come before the macports stuff in the various PATHs is sufficient to prevent the problems the GTK-OSX people seem to have with macports…

5.) Not a question, but an observation: GTK-OSX at the current (as of last night) build is bundling freetype and fontconfig of appropriate versions when the ‘jhbuild bootstrap && jhbuild build meta-gtk-osx-bootstrap && jhbuild build meta-gtk-osx-core’ sequence completes. Yes, I fixed the 64-bit building issue with the following lines in ~/.jhbuildrc-custom:

32-bit i386 build…

environ_append(“CFLAGS”,"-arch i386")
environ_append(“CXXFLAGS”,"-arch i386")
environ_append(“LDFLAGS”,"-arch i386")

And I setup the PATH properly with a ‘jhwrap’ script that sets up PATH to exclude the macports stuff and add ~/.local/bin to the PATH.

And that’s as far as I got last night in the build; downloaded most of the rest of the stuff, but the gtk patch stymied me since I wasn’t sure if it would even apply to the version I got. I am planning to do more tomorrow night or Saturday, or whenever I get more clues as to how to get revision 20839 of the gtk.patch patched gtk. And I’ll get there, sooner or later, but having this documented I think would be good.

This makes building ardour from source on Linux look like a positive cakewalk, even doing things like packaging a .deb or a .rpm (which I’ve done…) seem trivial (and 2.8.3 backported to Fedora 11 wasn’t trivial when doing it the ‘RPM way’ and rebuilding from source RPM, which I’ve already done…But Paul said as much in the article about the subject!

Minor edit: ‘fixed the 64-bit building issue’ is probably the wrong verbiage; there are several pieces of GTK-OSX that won’t build 64 bits, so I should say ‘worked around the 64-bit nonbuilding issue by forcing a 32-bit build’ instead. Sorry for the confusion.

I assume from your post that you are trying to follow the page here on building OS X native version of Ardour…

The simple answer is DON’T. There are several things I will say here, but the biggest one is simply do NOT EVER USE MACPORTS if you want to build Ardour on OS X. It is more than just removing it from your PATH, you would need to remove any flags it adds for compilations, env variables it modifies such as PKG_CONFIG_PATH, etc. Pretty much you ahve to remove everything it possibly does, and it still can break things in hard to see ways if you miss a minor detail. Just DO NOT DO IT.

You do not need to use the macports version of scons. You shouldn’t use it, nor should you install any dependencies via scons.

All this being said, I wouldn’t expect support for the OS X build process really. I would suggest getting on IRC with specific questions, but don’t hold your breath.

As Paul mentioned, the current version of GTK is very different in some important ways compared to what we were using and Snow Leopard compilation is not currently possible(Heck OS X compilation in general is not currently possible with current GTKOSX).

And yes compiling Ardour on Linux is a piece of cake compared to OS X.


there is no working GTK patch for current GTK (git) at this time. it is not possible to build ardour on OSX against current GTK. released versions are built against a “very old” version that has been patched up in many different ways. a new GTK patch will hopefully be done sometime next week - it will be a lot smaller since most of my patches are now in GTK itself.

you cannot build GTK-OSX 64 bit because it relies on Carbon for some functionality that does not seem to be available via Cocoa. i have no idea if/when this will change. the stuff that is needed by GTK is stuff that very few apps would ever need to do, and this may contribute to the lack of any apparent way to get it done with Cocoa. or it may just need the right person to track down the missing Cocoa APIs.


Looking forward to seeing the newer patch, then.

When I posted, I couldn’t remember the specifics of the 64 bit issue, but you nailed them. My reference is in the gtk-osx forum:

What’s so odd (to me) is that the same patching isn’t required on Linux. But in my reading and experimenting I see how different the native backend is from X11, and am quite impressed that you made it work at all, Paul. And on Linux the build is against much more recent GTK…


Thanks for the clarifications. That answers a number of my questions; meaning I’ll need to remove macports and go a different route for those pieces that are needed that were recommended to be installed via macports. I can do that easily enough. That should take enough time so that an updated patch against the stable moduleset of GTK might be available.

Looking at the sonames (sorry, too long on Linux and not enough time on OS X development yet) of the distributed .dylibs was pretty instructive. Very old GTK indeed.

Having said all that, it is documented in the GTK-OSX build stuff how to get older versions with jhbuild, but getting it to work with current GTK would be more useful.

Also, with the modifications to .jhbuildrc-custom for Snow Leopard, I successfully compiled gimp with jhbuild on my GTK-OSX tree on my Snow Leopard install. That does, of course, produce a 32-bit executable, and may not be the most desirable thing to do. And gimp is easier to build than Ardour anyway.

And I understand about not expecting much (or any) support. Just getting the patches and knowing the toolchain used is enough for me to do what I want to do, even if it takes me a lot of time to do it. I enjoy these sorts of challenges, and when I get a ‘home-brewed’ build actually running locally I will be a happy camper (just for the journey’s enjoyment!). And, as I said, I am not intending on distributing binaries of any kind at all. That’s part of Paul’s bread and butter; not going to go there as the troll did in another topic…

Also, as mentioned in a different topic, IRC isn’t an option for me for a couple of reasons. First, my firewall is configured to block all IRC to eliminate any infected Windows machines on my network becoming active spambots (and the size of my connection is inviting for spambotnets). Second, I communicate rather horribly in realtime chat situations. E-mail and forums work fine for me, though.

Having said all that, it is documented in the GTK-OSX build stuff how to get older versions with jhbuild, but getting it to work with current GTK would be more useful.

Hmm where is the documentation you found on this by the way, the only way I found to do it is to trick JHBuild in thinking you are using the newest version, and then roll the contents of that directory back manually.

Be wary of any files you compiled since installing Macports, it could easily be more than possible some of them got linked accidentally against macports which will cause problems for you later.

In as far as IRC, you could always utilize one of the web applets(Heck go to Help>Chat in Ardour;) to get around the firewall issues I believe if you wanted.

Hmm where is the documentation you found on this by the way, the only way I found to do it is to trick JHBuild in thinking you are using the newest version, and then roll the contents of that directory back manually.

Haven’t tried it, but here is the raw information:

Appreciate the pointers. Might try the web IRC. Chat logs kept anywhere? (That’s one thing I love about e-mail/forums is the ability to go back when I forget things…)

Heh thanks for the link, I was considering making my own moduleset specifically to help with building Ardour on occasion, but haven’t bothered yet.

I don’t think Chat logs are kept anywhere when using a browser client, but I could very easily be wrong.