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

Reply via email to