[sword-devel] ppc64le build error

[Greg Hellings]

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.hellings at 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 <scribe at 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 <jaak at 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 at 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 at 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 at 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 at 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 at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20190720/f6e34a2d/attachment-0001.html>