[Top][All Lists]

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

Re: regtests for previous stables failing

From: Thomas Morley
Subject: Re: regtests for previous stables failing
Date: Mon, 30 Oct 2017 11:53:27 +0100

2017-10-29 8:44 GMT+01:00 Werner LEMBERG <address@hidden>:
>>> But I get
>>> /home/hermann/lilypond-git/lily/ In member function
>>> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
>>> const':
>>> /home/hermann/lilypond-git/lily/ 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.
> Actually, it could be indeed a gcc version problem (or rather, a cpp
> problem).  In `' we have
>   #include FT_XFREE86_H
> which is defined by FreeType as
>     /* deprecated */
> which in turn is defined as
>   #define FT_FONT_FORMATS_H  <freetype/ftfntfmt.h>
> Using gcc 4.8.5 for compilation of lilypond works just fine on my
> GNU/Linux box, BTW.
> Maybe it helps if you replace the line
>   #include FT_XFREE86_H
> in file `' with
>   #include FT_FONT_FORMATS_H
> If this compiles successfully, you definitely have a cpp bug in the
> gcc version you use.
>     Werner

Hi Werner,

I was trying to compile old branches (stable/2.16 and stable/2.18)
with the software Ubuntu 16.04 distributes. So I'm not at bleeding
edge but far more up to date than back in the time 2.16 was released.
You could say I tried a manual bisect limited to large steps.

While 2.18 was successful applying compatibility-pathes, i.e.
  Issue 4364: Allow ImageMagick's compare to exit with status 1
  Build: Fix compilation with GNU make 4.0
2.16 failed so far.

Your patch
  Issue 3694: Use standard inclusion scheme for FreeType headers.
didn't apply to 2.16. so I tried to insert the code manually, which
seems to cure the above reported problem.
But I now get errors in texi-files like:
@itemx must follow @item
warning: @vindex should only appear at a line beginning (possibly
involving @rweb)
raising the section level of @unnumberedsubsubsec which is too low

I don't think it makes sense to continue trying to compile 2.16 with
recent versions of make, gcc etc

Using makepp may have some advantages for future development
(honestly, I don't know anything about it) but I can't see how it
could help with that old code.

Anyway, thanks a lot to all,

reply via email to

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