<div dir="ltr"><div><a href="https://app.vagrantup.com/ppc64le/boxes/fedora30">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 &quot;vagrant up --provider=libvirt&quot; if it doesn&#39;t default to that provider on a standard &quot;vagrant up&quot;).</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&#39;t know if you&#39;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 &lt;<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>&gt; 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>
&gt; Yes, it is a sizeable patch. Although there might be hacks around this<br>
&gt; issue, getting rid of the reserved identifiers and using the fixed-width<br>
&gt; types from &lt;cstdint&gt; seems to be the correct approach to take.<br>
&gt;<br>
&gt; I&#39;m not even sure the patch applies correctly to Sword SVN trunk, but<br>
&gt; since this issue has long been fixed in Sword++, I referred to this<br>
&gt; commit in hopes to accelerate this getting fixed for Sword as well. I<br>
&gt; think it would not benefit anyone if Sword was left failing on Fedora<br>
&gt; rawhide.<br>
&gt;<br>
&gt;<br>
&gt; +Jaak<br>
&gt;<br>
&gt;<br>
&gt; On 18.07.19 06:47, Greg Hellings wrote:<br>
&gt;&gt; That is a rather sizeable patch. I don&#39;t want to just apply it wholesale to<br>
&gt;&gt; the Sword engine without some input from people who know more about the<br>
&gt;&gt; code than I do. It should, however, be workable if Troy doesn&#39;t have a more<br>
&gt;&gt; permanent fix in mind.<br>
&gt;&gt;<br>
&gt;&gt; --Greg<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jul 17, 2019 at 4:52 PM Jaak Ristioja &lt;<a href="mailto:jaak@ristioja.ee" target="_blank">jaak@ristioja.ee</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; In Sword++ we fixed [1] this by using the fixed-width integer types<br>
&gt;&gt;&gt; provided by &lt;cstdint&gt;. Note also that some certain names containing<br>
&gt;&gt;&gt; underscores are reserved to the C++ implementation [2], e.g. names<br>
&gt;&gt;&gt; beginning with underscores and names containing adjacent underscores.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Best regards,<br>
&gt;&gt;&gt; Jaak<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [1]: Feel free to integrate<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href="https://github.com/swordxx/swordxx/commit/3934674fd8db1302c7777c323c0a56235292d6d7" rel="noreferrer" target="_blank">https://github.com/swordxx/swordxx/commit/3934674fd8db1302c7777c323c0a56235292d6d7</a><br>
&gt;&gt;&gt; back to Sword. In Sword++ most of these type names were later prefixed<br>
&gt;&gt;&gt; with std::, e.g. std::uint64_t instead of plain uint64_t.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [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>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 17.07.19 17:52, Greg Hellings wrote:<br>
&gt;&gt;&gt;&gt; I got an automated report this week that Sword 1.8.1 has begun failing to<br>
&gt;&gt;&gt;&gt; build on ppc64le architecture with type redefinition errors. The errors<br>
&gt;&gt;&gt; are<br>
&gt;&gt;&gt;&gt; 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>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; To copy from that link, the relevant error is:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;  /usr/include/asm-generic/int-l64.h:29:25: error: conflicting<br>
&gt;&gt;&gt;&gt; declaration &#39;typedef long int __s64&#39;<br>
&gt;&gt;&gt;&gt;     29 | typedef __signed__ long __s64;<br>
&gt;&gt;&gt;&gt;        |                         ^~~~~<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;  /usr/include/asm-generic/int-l64.h:30:23: error: conflicting<br>
&gt;&gt;&gt;&gt; declaration &#39;typedef long unsigned int __u64&#39;<br>
&gt;&gt;&gt;&gt;     30 | typedef unsigned long __u64;<br>
&gt;&gt;&gt;&gt;        |                       ^~~~~<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I try to shy away from knowing too much about C&#39;s typing system. I can<br>
&gt;&gt;&gt;&gt; easily locate the places in our code where we are defining those types<br>
&gt;&gt;&gt;&gt; ourself. However, I don&#39;t want to mess up proper detection and<br>
&gt;&gt;&gt;&gt; definition of them in a patch if I can help it.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --Greg<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt;&gt;&gt;&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt;&gt;&gt;&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt;&gt;&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt;&gt;&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt;&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt;&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt; 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>