lilypond-devel
[Top][All Lists]
Advanced

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

Re: Strange space between beam and slur


From: Lukas-Fabian Moser
Subject: Re: Strange space between beam and slur
Date: Tue, 25 Jun 2019 21:56:52 +0200

Hi David,

> @gcc experts (hence posting to devel also): Unfortunately, I cannot
> > build 2.19.15 on my machine because of errors of the type:
> >
> > /home/lukas/git/lilypond/lily/include/smobs.tcc:98:25: error: invalid
> > conversion from 'int' to 'scm_unused_struct* (*)(SCM, SCM) {aka
> > scm_unused_struct* (*)(scm_unused_struct*, scm_unused_struct*)}'
> > [-fpermissive]
> >      scm_set_smob_equalp (smob_tag_, Super::equal_p);
> >
> > I suspect that this is a case of some conversions having become
> > illegal for later versions of gcc. Is there a cheap way to make the
> > build succeed in order to be able to bisect for the
> > misplaced-note-head bug?
>
> I think I used a few cherry-picks commits for building.  Embarrassingly,
> it doesn't appear like I have them in a branch.  They were a few C++
> commits, a few Texinfo ones, some stuff related to freetype.
>
My knowledge about the interal workings and building procedures is so close
to nil that I don't even understand the relation of your answer to my
question. I'm really sorry since I expect that this is entirely my fault!

Anyway, I now succeded in compiling 2.19.15  by downgrading to GCC 5.5.0
(GCC 4.8.5 didn't pass autogen.sh, and GCC 6.5.0 aborted during compilation
just like my "usual" GCC 7.4.0).

The misplaced-note-head bug (as exposed in the MWE in
https://sourceforge.net/p/testlilyissues/issues/5303/) first appears with:

commit cb6024decee0aafd84baafe34115fc1b2d179df6
Author: David Kastrup <address@hidden>
Date:   Thu Nov 13 21:13:12 2014 +0100

    Issue 216: ability to change staff line spacing inside a \layout{} block

    This uses the staff-space setting from the \layout block (if set) for
    determining staff spacing.

    It apparently does not help with horizontal spacing, though.

:040000 040000 d7f8491fd6749961632b4d85c8b9ab7e0db2bd9f
ba74f06021e49cec6b6702071edc245a0beb70bf M    lily

Best
Lukas


reply via email to

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