[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