David Kastrup <d...@gnu.org> writes: > Han-Wen Nienhuys <hanw...@gmail.com> writes: > >> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup <d...@gnu.org> wrote: >> >>> Han-Wen Nienhuys <hanw...@gmail.com> writes: >>> >>> > This surprises me greatly. I just checked >>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this >>> > morning, and I can execute >>> > >>> > ./autogen.sh ; make -j4 >>> > >>> > just fine. In fact, I actually did test this before pushing this morning. >>> > >>> > Could it be that you forgot to run autogen.sh ? >>> >>> lilypond-patchy-staging starts from a fresh directory, so no. It >>> wouldn't get anywhere without running autogen.sh. >>> >> >> The build log talks about >> >> autogen.sh --noconfigure >> >> can you confirm that with " ./autogen.sh && make -j4" it also fails? >> >> I cannot vouch for all software versions being the same as yours, >>> obviously. >>> >> >> Can you provide me with some recipe to reproduce the problem? Can you tell >> me what distribution you use? I could use Docker to recreate your setup. > > Just current Ubuntu eoan.
The following patch makes the commit you pushed compile: diff --git a/lily/pango-font.cc b/lily/pango-font.cc index 8eece690c8..587ed3d4f3 100644 --- a/lily/pango-font.cc +++ b/lily/pango-font.cc @@ -17,6 +17,10 @@ along with LilyPond. If not, see <http://www.gnu.org/licenses/>. */ +// Necessary for supporting pango_context_new() and +// pango_context_set_font_map() in Pango < 1.22 +#define PANGO_ENABLE_BACKEND + #include <pango/pangoft2.h> #include "freetype.hh" #include FT_XFREE86_H Never trust a comment. It would seem that without that define, one would need to include more/other/different headers to get the used types defined. At least in the Pango version I have installed. -- David Kastrup