Build Error Version 2.7.1 (and 2.6.1)

I am getting the following error when building from source.

/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:389: error: no matching function for call to ‘boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>::destroy(std::pair*)’

This error occurs when compiling the file gtk2_ardour/tempo_lines.cc which #includes gtk2_ardour/tempo_lines.h.

There are a couple of warnings that come up, these appear to be related to an asset function that is “has no effect”.

It looks like a problem with a C++ template that is defined in the boost library. I have tried two different versions of the boost library (1.33 and 1.37) and both give the same problem.

Note how the error appears to be deep within the C++ _Rb_tree class, but I am assuming this is just an effect of using a template defined elsewhere.

Any ideas how to fix this?

John T.

PS version 2.5 builds without error.

The full error is here:

g++ -o gtk2_ardour/tempo_lines.o -c -Woverloaded-virtual -DPACKAGE=\"gtk2_ardour\" -DLIBSIGC_DISABLE_DEPRECATED -DLOCALEDIR=\"/usr/share/locale\" -DVERSIONSTRING=\"2.7.1\" -O3 -fomit-frame-pointer -ffast-math -fstrength-reduce -pipe -DARCH_X86 -mmmx -march=i686 -msse -mfpmath=sse -DUSE_XMMINTRIN -DBUILD_SSE_OPTIMIZATIONS -Wall -DHAVE_LIBLO -Ilibs -DENABLE_NLS -DPACKAGE=\"gtk2_ardour\" -pthread -DFFT_ANALYSIS -DUSE_RUBBERBAND -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Ilibs/pbd -Ilibs/surfaces/control_protocol -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -Ilibs/sigc++2 -Ilibs/glibmm2 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -Ilibs/gtkmm2/atk -I/usr/include/glib-2.0 -Ilibs/gtkmm2/pango -Ilibs/vamp-sdk -I/usr/include/freetype2 -Igtk2_ardour -Ilibs/gtkmm2/gtk -Ilibs/libsndfile/src -Ilibs/ardour -I/usr/local/include -Ilibs/midi++2 -Ilibs/rubberband -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/libxml2 -Ilibs/gtkmm2/gdk -Ilibs/libsndfile -Ilibs/libgnomecanvasmm -I. -Ilibs/gtkmm2ext gtk2_ardour/tempo_lines.cc libs/glibmm2/glibmm/containers.h: In member function ‘typename Glib::List_Iterator_Base::reference Glib::SList_Iterator::operator*() const’: libs/glibmm2/glibmm/containers.h:181: warning: statement has no effect libs/gtkmm2/gtk/gtkmm/treeview.h: In member function ‘int Gtk::TreeView::append_column_editable(const Glib::ustring&, const Gtk::TreeModelColumn&)’: libs/gtkmm2/gtk/gtkmm/treeview.h:1419: warning: statement has no effect libs/gtkmm2/gtk/gtkmm/treeview.h: In function ‘void Gtk::TreeView_Private::_connect_auto_store_editable_signal_handler(Gtk::TreeView*, Gtk::CellRenderer*, const Gtk::TreeModelColumn&)’: libs/gtkmm2/gtk/gtkmm/treeview.h:1652: warning: statement has no effect /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h: In member function ‘void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::destroy_node(std::_Rb_tree_node<_Val>*) [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’: /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:1097: instantiated from ‘void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_erase(std::_Rb_tree_node<_Val>*) [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’ /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:571: instantiated from ‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’ /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_map.h:92: instantiated from here /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:389: error: no matching function for call to ‘boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>::destroy(std::pair*)’ /usr/include/boost/pool/pool_alloc.hpp:210: note: candidates are: void boost::fast_pool_allocator::destroy(T*) [with T = std::pair, UserAllocator = boost::default_user_allocator_new_delete, Mutex = boost::details::pool::null_mutex, unsigned int NextSize = 8192u] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h: In member function ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_create_node(const _Val&) [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’: /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:794: instantiated from ‘typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, const _Val&) [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’ /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:883: instantiated from ‘std::pair::iterator, bool> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(const _Val&) [with _Key = double, _Val = std::pair, _KeyOfValue = std::_Select1st<std::pair >, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’ /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_map.h:360: instantiated from ‘std::pair<typename std::_Rb_tree<_Key, std::pair, std::_Select1st<std::pair >, _Compare, _Alloc>::iterator, bool> std::map<_Key, _Tp, _Compare, _Alloc>::insert(const std::pair&) [with _Key = double, _Tp = Gnome::Canvas::SimpleLine*, _Compare = std::less, _Alloc = boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>]’ gtk2_ardour/tempo_lines.cc:52: instantiated from here /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_tree.h:367: error: no matching function for call to ‘boost::fast_pool_allocator<std::pair, boost::default_user_allocator_new_delete, boost::details::pool::null_mutex, 8192u>::construct(std::pair*, const std::pair&)’ /usr/include/boost/pool/pool_alloc.hpp:208: note: candidates are: void boost::fast_pool_allocator::construct(T*, const T&) [with T = std::pair, UserAllocator = boost::default_user_allocator_new_delete, Mutex = boost::details::pool::null_mutex, unsigned int NextSize = 8192u] scons: *** [gtk2_ardour/tempo_lines.o] Error 1 scons: building terminated because of errors.

I’d guess too old gcc; 4.0.3 is coming up three years now.
Also the /usr/lib/gcc/i486-linux-gnu part seems …old.

I’d guess too old gcc; 4.0.3 is coming up three years now.

I was dreading someone saying this :-(. I guess I am going to spend tommorrow building gcc/g++ 4.3.3.

I was hoping the web site http://ardour.org/building was correct in saying gcc/g++ 3.x or greater.

John T.

It might not actually be too old, there might just be a bug in that version affecting Ardour/boost (or the web site might be wrong!).
There’s also a chance I don’t know what I’m talking about… :wink:

That said, I’d consider updating the distro alltogether if I were you.

That said, I’d consider updating the distro alltogether if I were you

Nope… I am not going to upgrade the distro - I have had my fingers burnt already doing that - see one of my other posts on this forum http://ardour.org/node/2185

There’s also a chance I don’t know what I’m talking about… :wink:

I think you have a point. I had my doubts about gcc 4.0.3 long before I got round to posting my original question.

Not to worry, I have built gcc from source before, so I will just have to get out the old brains cells and try and remember what I did…

JT

I have made a little bit of progress but still not solved the problem. Having built a version of gcc/g++ 4.3.3 from source and put this in my $PATH, ardour 2.7.1 appears to build, i.e. my scons PREFIX=/USR is
successful and eventually returns:

[snip]..... g++ -o libs/surfaces/powermate/libardour_powermate.so -O3 -fomit-frame-pointer -ffast-math -fstrength-reduce -pipe -DARCH_X86 -mmmx -march=i686 -msse -mfpmath=sse -DUSE_XMMINTRIN -DBUILD_SSE_OPTIMIZATIONS -Wl,--export-dynamic -pthread -shared libs/surfaces/powermate/interface.os libs/surfaces/powermate/powermate.os -Llibs/pbd -Llibs/surfaces/control_protocol -Llibs/midi++2 -Llibs/ardour -Llibs/sigc++2 -Llibs/glibmm2 -lardour -lardour_cp -lsigc++2 -lpbd -lmidi++ -lxml2 -lz -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -lglibmm2 scons: done building targets.

Note the previous problem c++ source file tempo_lines.cc does compile
successfully.

However, when I try to install with: sudo scons install, the system appears to start the install process but then for some reason tries to re-compile temo_lines.cc again and this time fails with exactly the same error as when I was using gcc 4.0.3; I can see that, in this instance it is using the 4.0.3, rather than the 4.3.3 include files. It also takes a very long time to fail - almost longer than the initial build, because it is, for some reason, building lots of other files as well; I do not understand why it is building these files, surely all the targets were built with the first scons command.

This would suggest that the scons install is, for some reason, ignoring my path. This leads to the question why would the initial scons honour my PATH and scons install ignore it? I could of course remove gcc/g++
4.0.3 from my system but the debian package manager is telling me that lots of things depend on gcc/g++ so that is going to be a hassle.

Can anyone shed any light?

John T

My guess is you didn’t do a ‘scons -c’ in the ardour dir first, to clean up the 4.0.3-configured files.
In fact, I’d remove the ardour dir entirely, untar it again and recompile it.

One way of “removing” 4.0.3 is to simply rename the binaries to, say, gcc_403 and g++_403, but I don’t think that’s necessary

I’d remove the ardour dir entirely, untar it again and recompile it.

Thats the first thing a did. I think I will try changing the symklinks that are /usr/bin/gcc and /usr/bin/g++ and point them at my gcc-4.3.3 that I built from source and report back; they currently point at /usr/bin/gcc-4.0 etc. I will remove the ardour directory and untar again before I start as well.

John T.

We have success; I have a working version of Ardour 2.7.1. It appears that putting the path for gcc version 4.3.3 into the PATH environment variable is good enough for the inital scons command but does not work for scons install.

I did as described in my previous post: /usr/bin/g++ and /usr/bin/g++ are originally symlinks to the executables gcc-4.0 and g+±4.0 respectively. Rather than using the PATH Environement variable, I changed these symlinks to point to /opt/gcc/bin/gcc and /opt/gcc/bin/g++ respectively; /opt/gcc being the location where I installed gcc 4.3.3.

cd /usr/bin
sudo ln -sf /opt/gcc/bin/gcc
sudo ln -sf /opt/gcc/bin/g++

With this configuration both scons commands work successfully. In particular the scons install command does not try and re-compile lots of targets, which is the case if gcc is called by setting the PATH variable.

Then providing I have /opt/gcc/lib in the LD_LIBRARY_PATH variable then ardour runs.

So the upshot of all this is that version 4.0.3 of the gcc compiler does not build ardour v2.6.1 or v2.7.1. In case anyone else comes across this problem and they want to build another version of gcc from source, as I did, the instructions can be found here:
http://gcc.gnu.org/install/configure.html

You only need to download the gcc-core and the gcc-g++ (C++) tar balls. Both untar into the same directory - in my case gcc-4.3.3. The above instructions tell you to run the configure script in a separate directory to the source directory that the gcc tar balls create. I configured gcc as follows:

…/gcc-4.3.3/configure --prefix=/opt/gcc --with-cpu=pentium4 --with-arch=pentium4
–with-tune=pentium4

Mega thanks go to Dr Peder for spotting straight away what the problem was and special thanks to all who actually had the patience to read the whole thread.

JT