Re: GUB fail with smob templates

[Phil Holmes]

----- Original Message ----- 
From: "David Kastrup" <address@hidden>
To: "Phil Holmes" <address@hidden>

> > Fails compiling for a different target now.  Logfile attached again.
>
> /home/gub/gub/target/freebsd-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/smobs.tcc:136: 
> error: invalid operands of types 'bool' and 'int' to binary 'operator=='
>
> So now we cannot compare a bool with an int?  What is this, Pascal?
>
> The error message also does not fit the current line in smobs.tcc:
>
>    136   if (static_cast<SCM (Super::*)()>(&Super::mark_smob) !=
>    137       static_cast<SCM (Super::*)()>(&Smob_base<Super>::mark_smob))
>
> Previous versions had
>    136   if (Super::type_p_name_ != 0)
>
> which is still not the best fit, but at least there is an integer
> involved.

I agree with what you say about the strange error message.  Just to confirm, 
though: lines 136-7 as given in the error message are the lines to be found 
in smobs.tcc.

> > Do you reckon we should continue to try to get this fixed, or just
> > bite the bullet and update gcc and see if that works?
>
> It would appear that the versions of GCC are somewhat basic regarding
> their template support.  Now what is really surprising to me is that
> 2.19.15 went ahead without much of a hitch.  Because the changes of
> 2.19.16, as compared to 2.19.15, seem to be more on the surface.
>
> Since we _did_ get 2.19.15 through, 2.19.16 should be a breeze.
> However, the current batch of error messages is totally baffling to me.
> The current error messages just do not appear to match the flagged lines
> at all.
>
> So I'm poking around quite in the dark.  It's probably silly to ask
> since you are not building for the first time, but you are sure that you
> are working from the current origin/release/unstable ?

Had me worried.  I checked and I am.

> To me it looks like updating gcc to some newer version might make sense.
> Starting with version 2.19.15, we are relying more on templates than
> before.  And working with gcc versions that go bonkers in entirely
> puzzling ways is likely going to cause more trouble than the one we are
> having right now anyway.


I'll start looking at it now.

--
Phil Holmes