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