lilypond-devel
[Top][All Lists]
Advanced

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

Re: Unable to run make on older releases, while doing bug-reseach


From: Thomas Morley
Subject: Re: Unable to run make on older releases, while doing bug-reseach
Date: Sun, 23 Feb 2020 13:50:34 +0100

Am So., 23. Feb. 2020 um 13:14 Uhr schrieb David Kastrup <address@hidden>:
>
> Thomas Morley <address@hidden> writes:
>
> > Hi,
> >
> > I'm currently trying to hunt down a possible bug (I wrote possible,
> > because I may very well ne intended behaviour. I don't know yet)
> > Using our prereleased installers I found it happened between 2.19.25
> > and 2.19.26.
> >
> > Then I switched to git, in order to identify the patch which causes
> > the changed behaviour.
> >
> > Alas, I'm not able to run 'make' successfully on any old release or 
> > inbetween.
> >
> > I do (always with guile1):
> >
> >  2053  rm -fr build/
> >  2054  git checkout release/2.19.25-1
> >  2055  mkdir -p build/
> >  2056  cd build/
> >  2057  ../configure
> >  2058  make -j3 CPU_COUNT=3
> >
> > I always get:
> >
> > In file included from 
> > /home/hermann/lilypond-git/lily/include/smobs.hh:367:0,
> >                  from /home/hermann/lilypond-git/lily/include/input.hh:24,
> >                  from 
> > /home/hermann/lilypond-git/lily/include/translator.hh:26,
> >                  from 
> > /home/hermann/lilypond-git/lily/include/engraver.hh:24,
> >                  from 
> > /home/hermann/lilypond-git/lily/metronome-engraver.cc:23:
> > /home/hermann/lilypond-git/lily/include/smobs.tcc: In instantiation of
> > 'static void Smob_base<Super>::init() [with Super =
> > Callback_wrapper]':
> > /home/hermann/lilypond-git/lily/include/smobs.tcc:111:10:   required
> > from 'Scm_init Smob_base<Callback_wrapper>::scm_init_'
> > /home/hermann/lilypond-git/lily/include/smobs.hh:162:35:   required
> > from 'static scm_t_bits Smob_base<Super>::smob_tag() [with Super =
> > Callback_wrapper; scm_t_bits = long unsigned int]'
> > /home/hermann/lilypond-git/lily/include/smobs.tcc:58:3:   required
> > from 'static scm_unused_struct* Smob_base<Super>::register_ptr(Super*)
> > [with Super = Callback_wrapper; SCM = scm_unused_struct*]'
> > /home/hermann/lilypond-git/lily/include/smobs.hh:277:43:   required
> > from 'scm_unused_struct* Simple_smob<Super>::smobbed_copy() const
> > [with Super = Callback_wrapper; SCM = scm_unused_struct*]'
> > /home/hermann/lilypond-git/lily/include/listener.hh:196:64:   required
> > from 'static scm_unused_struct* Callback_wrapper::make_smob() [with T
> > = Metronome_mark_engraver; Arg = Stream_event*; void (T::*
> > callback)(Arg) = &Metronome_mark_engraver::listen_tempo_change; SCM =
> > scm_unused_struct*]'
> > /home/hermann/lilypond-git/lily/metronome-engraver.cc:64:1:   required from 
> > here
> > /home/hermann/lilypond-git/lily/include/smobs.tcc:143:37: error:
> > invalid conversion from 'int' to 'const char*' [-fpermissive]
> >        SCM subr = scm_c_define_gsubr (Super::type_p_name_, 1, 0, 0,
> >                   ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                                       (scm_t_subr) smob_p);
> >                                       ~~~~~~~~~~~~~~~~~~~~
>
> Ah that abomination.  Sorry for seeing this only now.  You'll need to
> cherry-pick
>
> commit 67cd07e55d5ec908c246ae543e480d367b61d6b3
> Author: David Kastrup <address@hidden>
> Date:   Fri Jun 3 14:21:55 2016 +0200
>
>     Issue 4878: Make type_p_name_ always char pointer
>
>     This avoids the pitfalls cured by issue 4783 without the
>     associated inconvenience when no predicate is desired.
>
> every time, probably using git cherry-pick -n (in order not to confuse
> bisection) followed by git reset --hard once you know whether the commit
> is good or bad.
>
> Maybe we need to set up a branch of cherry-picks for getting older stuff
> to compile on newer compilers.
>
> --
> David Kastrup
> My replies have a tendency to cause friction.  To help mitigating
> damage, feel free to forward problematic posts to me adding a subject
> like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Hi David,

thanks for the hint, I'll try to narrow done the cause of my recent
bugreport, then.
http://lilypond.1069038.n5.nabble.com/dynamic-is-strange-since-2-19-26-td229588.html

I really hope it does not turn out to be showstopper for 2.20.


Thanks,
  Harm



reply via email to

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