Re: Source compilation errors with c++14/GCC6

[David Kastrup]

Jon Ciesla <address@hidden> writes:

> On Wed, Mar 2, 2016 at 3:00 PM, David Kastrup <address@hidden> wrote:
>
>> Jon Ciesla <address@hidden> writes:
>>
>> > Lilypond 2.19.36/7 fails to build with GCC6 using the c++14 std, which is
>> > the new default for GCC6, as present in Fedora 24+.  Attached is a patch
>> > allowing Lilpond 2.19.37 to build.  Please review and adopt if
>> applicable.
>> > If there are better corrections than what I've done here, please let me
>> > know and I'll update our patch, at least until a future release builds
>> > unpatched.
>>
>> The proposed changes are pretty much unilaterally horrible.
>>
>>    // code maintenance while being harder to understand and quite
>>    // trickier in its failure symptoms when things go wrong.  So we
>>    // just use a static zero as "not here" indication.
>> -  static const int type_p_name_ = 0;
>> +  static const int type_p_name_ = NULL;
>>
>> Why would a const int be set to NULL, a pointer constant?
>>
>> And since that apparently doesn't even work, you afterwards apply
>> reinterpret_casts (pretty much the worst kind of cast) on everything.
>>
>> What kind of error message are you getting for the original code?
>>
>> --
>> David Kastrup
>>
>> _______________________________________________
>> bug-lilypond mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>
> Original error messages here, i build.log:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1307746
>
> This is an additional reference:
>
> https://gcc.gnu.org/gcc-6/porting_to.html
>
> Alternative suggestions are more than welcome.

Tracker issue: 4783 (https://sourceforge.net/p/testlilyissues/issues/4783/)
Rietveld issue: 287350043 (https://codereview.appspot.com/287350043)
Issue description:
  Remove Smob::type_p_name_ default  This was the single most
  problematic thing across C++ compilers and standards. Foregoing it
  means a hassle, but using it turned out to be worse.

And I _strongly_ suspect this to be a GCC6 error anyway but I'm not
interested in hunting this down.

-- 
David Kastrup