lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: regtests for previous stables failing


From: David Kastrup
Subject: Re: regtests for previous stables failing
Date: Sat, 28 Oct 2017 19:06:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 2017-10-28 18:27 GMT+02:00 David Kastrup <address@hidden>:
>> Thomas Morley <address@hidden> writes:
>>
>>> 2017-10-27 23:13 GMT+02:00 David Kastrup <address@hidden>:
>>>>
>>>> It's a bit tricky.  Maybe we should cherry-pick the necessary
>>>> compatibility patches to the stable branches' tips?  If you want to
>>>> bisect, you'd need to skim them in as well, I guess.
>>>
>>> The compability patch is likely:
>>>
>>> commit [r2545fab01a601743bb3ecc18942cf14263ccfc6c]
>>> Author: David Kastrup <address@hidden>
>>> Date:   Sat May 2 00:35:35 2015 +0200
>>>
>>>     Issue 4364: Allow ImageMagick's compare to exit with status 1
>>>
>>>     Apparently Ubuntu 15.04 has a version of "compare" that cannot be easily
>>>     persuaded to return anything but exit status 1 (which indicates
>>>     dissimilar images but no actual error condition) so we allow this in
>>>     script/build/output-distance.py in order to keep "make check" from
>>>     failing.
>>>
>>>     This patch is somewhat artless but does the trick.
>>>
>>> Putting this one on top of my local copy of remotes/origin/stable/2.18
>>> makes it work with GNU Make 4.1
>>>
>>> Though, not for my 2.16.-branch.
>>> I get:
>>> ~/lilypond-git/build (dev/2-16-test)$ make -j5
>>> /home/hermann/lilypond-git/stepmake/stepmake/po-targets.make:41: ***
>>> recipe commences before first target.  Stop.
>>> Not sure what it makes it fail here but succeeds for 2.18.
>>
>> commit 1ca9814191d16fd3c571d93035247db039254fc1
>> Author: Julien Rioux <address@hidden>
>> Date:   Mon Oct 28 21:42:43 2013 +0100
>>
>>     Build: Fix compilation with GNU make 4.0
>>
>>     Fix "recipes commence before first target" error.
>>
>>     Patch from Thomas Klausner.
>
> Thanks, nor direct error for make anymore.
>
> But I get
> /home/hermann/lilypond-git/lily/pango-font.cc: In member function
> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
> const':
> /home/hermann/lilypond-git/lily/pango-font.cc:166:55: error:
> 'FT_Get_X11_Font_Format' was not declared in this scope
>    bool is_ttf = string (FT_Get_X11_Font_Format (ftface)) == "TrueType";
>
> A gcc-version-problem?

More likely a freetype problem.

commit 7705e46966bfa05015fb9fb20c68da844ab88028
Author: Werner Lemberg <address@hidden>
Date:   Thu Dec 5 15:01:48 2013 +0100

    Issue 3694: Use standard inclusion scheme for FreeType headers.
    
    The most recent FreeType release (2.5.1) has changed locations for header
    files.  Using the standard way, this is not visible to applications.

Though I'd expect a different error to be honest.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]