[sword-devel] ppc64le build error

Greg Hellings greg.hellings at gmail.com
Sun Jul 21 12:27:14 MST 2019 

On Sun, Jul 21, 2019 at 1:07 PM Troy A. Griffitts <scribe at crosswire.org>
wrote:

> 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:
>
Vagrant is a whole world of amazing things, that can really make working
with VMs easier, once everything works right. I use it extensively when I
need to test things on RHEL, CentOS, different flavors of Fedora, Ubuntu,
etc. It's easiest when backed by Virtual Box, as that is the default
provider for people on Mac and Windows and many who run on Linux. But many
other VM providers can be used: libvirt, OpenStack, Hyper-V, VMWare, etc.
It's a great way to manage your VMs.

> ==> 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.
>
Shoot. The box stopped there for me, too, and I assumed it was because I am
currently at my mom's and I'm not on my local network. More likely this is
because the box wasn't configured exactly correctly by the people who
created it. I'll see if there's anything I can do to fix that.

--Greg

> 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>
> 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
>>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.orghttp://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/a0cc45ad/attachment.html>

More information about the sword-devel mailing list