[sword-devel] ppc64le build error

Troy A. Griffitts scribe at crosswire.org
Sun Jul 21 11:06:16 MST 2019


Well, this sounds cool.  Thank you for opening the world of Vagrant to
me.  I think I am doing this right.  I have run the commands and am
waiting with this as my last output:

==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     -1
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        9216
==> default:  -- Sound Type:   
==> default:  -- Keymap:            en-us
==> default:  -- TPM Path:         
==> default:  -- INPUT:             type=mouse, bus=ps2
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...

It's been sitting there for quite some time and an htop shows 2 of my
cores spinning at 100% occupied by qemu...

I noticed the vnc reference at localhost and tried to connect to that
and sure enough, I get connected to a boot screen which last says:

Booting from Hard Disk...

But nothing else happens?  Should I keep waiting?  Do I need to escalate
permissions to root?  Do I need to add my username to some new vagrant
group?  Do I need to reboot my box for my dnf install stuff to "take"? 
Any advice would be appreciated.  Looking forward to adding this to my
toolbox once I learn.

Troy


On 7/20/19 9:28 PM, Greg Hellings 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 <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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/20190721/a820b3f6/attachment.html>


More information about the sword-devel mailing list