<div dir="ltr"><div>I did just kick off this latest build against Rawhide and still got the same error:</div><div><br></div><div><a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=36383425">https://koji.fedoraproject.org/koji/taskinfo?taskID=36383425</a></div><div><br></div><div>--Greg<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 20, 2019 at 11:28 PM Greg Hellings <<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><a href="https://app.vagrantup.com/ppc64le/boxes/fedora30" target="_blank">https://app.vagrantup.com/ppc64le/boxes/fedora30</a></div><div><br></div><div>That should allow you to bring up a local VM with Fedora 30 on ppc64le using Vagrant. Only works on systems with a libvirt backend to Vagrant (sudo dnf install vagrant vagrant-libvirt should do the trick on a Fedora workstation, followed by "vagrant up --provider=libvirt" if it doesn't default to that provider on a standard "vagrant up").</div><div><br></div><div>The build error was in Rawhide, though, and seems to have been due to changes in the headers. Errors from a similar cause have come and gone from time to time in the past. Sometimes they come and go in automated builds in a transient manner. I don't know if you'll see it when you try or not when you try.<br></div><div><br></div><div>--Greg<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 20, 2019 at 10:36 PM Troy A. Griffitts <<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anyone have access to a PPC64LE box I can play on?<br>
<br>
On 7/18/19 12:04 AM, Jaak Ristioja wrote:<br>
> Yes, it is a sizeable patch. Although there might be hacks around this<br>
> issue, getting rid of the reserved identifiers and using the fixed-width<br>
> types from <cstdint> seems to be the correct approach to take.<br>
><br>
> I'm not even sure the patch applies correctly to Sword SVN trunk, but<br>
> since this issue has long been fixed in Sword++, I referred to this<br>
> commit in hopes to accelerate this getting fixed for Sword as well. I<br>
> think it would not benefit anyone if Sword was left failing on Fedora<br>
> rawhide.<br>
><br>
><br>
> +Jaak<br>
><br>
><br>
> On 18.07.19 06:47, Greg Hellings wrote:<br>
>> That is a rather sizeable patch. I don't want to just apply it wholesale to<br>
>> the Sword engine without some input from people who know more about the<br>
>> code than I do. It should, however, be workable if Troy doesn't have a more<br>
>> permanent fix in mind.<br>
>><br>
>> --Greg<br>
>><br>
>> On Wed, Jul 17, 2019 at 4:52 PM Jaak Ristioja <<a href="mailto:jaak@ristioja.ee" target="_blank">jaak@ristioja.ee</a>> wrote:<br>
>><br>
>>> In Sword++ we fixed [1] this by using the fixed-width integer types<br>
>>> provided by <cstdint>. Note also that some certain names containing<br>
>>> underscores are reserved to the C++ implementation [2], e.g. names<br>
>>> beginning with underscores and names containing adjacent underscores.<br>
>>><br>
>>><br>
>>> Best regards,<br>
>>> Jaak<br>
>>><br>
>>><br>
>>> [1]: Feel free to integrate<br>
>>><br>
>>> <a href="https://github.com/swordxx/swordxx/commit/3934674fd8db1302c7777c323c0a56235292d6d7" rel="noreferrer" target="_blank">https://github.com/swordxx/swordxx/commit/3934674fd8db1302c7777c323c0a56235292d6d7</a><br>
>>> back to Sword. In Sword++ most of these type names were later prefixed<br>
>>> with std::, e.g. std::uint64_t instead of plain uint64_t.<br>
>>><br>
>>> [2]: See <a href="https://stackoverflow.com/a/228797" rel="noreferrer" target="_blank">https://stackoverflow.com/a/228797</a> for a good summary on this.<br>
>>><br>
>>><br>
>>> On 17.07.19 17:52, Greg Hellings wrote:<br>
>>>> I got an automated report this week that Sword 1.8.1 has begun failing to<br>
>>>> build on ppc64le architecture with type redefinition errors. The errors<br>
>>> are<br>
>>>> reported here: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1730318" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1730318</a><br>
>>>><br>
>>>> To copy from that link, the relevant error is:<br>
>>>><br>
>>>> /usr/include/asm-generic/int-l64.h:29:25: error: conflicting<br>
>>>> declaration 'typedef long int __s64'<br>
>>>> 29 | typedef __signed__ long __s64;<br>
>>>> | ^~~~~<br>
>>>><br>
>>>> /usr/include/asm-generic/int-l64.h:30:23: error: conflicting<br>
>>>> declaration 'typedef long unsigned int __u64'<br>
>>>> 30 | typedef unsigned long __u64;<br>
>>>> | ^~~~~<br>
>>>><br>
>>>> I try to shy away from knowing too much about C's typing system. I can<br>
>>>> easily locate the places in our code where we are defining those types<br>
>>>> ourself. However, I don't want to mess up proper detection and<br>
>>>> definition of them in a patch if I can help it.<br>
>>>><br>
>>>> --Greg<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
>>>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>>>> Instructions to unsubscribe/change your settings at above page<br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
>>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>>> Instructions to unsubscribe/change your settings at above page<br>
>>><br>
>><br>
>> _______________________________________________<br>
>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>> Instructions to unsubscribe/change your settings at above page<br>
>><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div>
</blockquote></div>