[sword-devel] ppc64le build error
Greg Hellings
greg.hellings at gmail.com
Mon Aug 19 09:42:30 MST 2019
Troy,
I have had issues with getting SSH working in the pcc64le system, which
means Vagrant won't work. But I can bring up a Rawhide VM with the
following steps:
1: Download the qcow2 image from from here:
https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/rawhide/Cloud/ppc64le/images/
2: Install the necessary utilities: sudo dnf install genisoimage
cloud-utils qemu-system-ppc-core
3: Create a file (I call mine config.yaml) with the following content:
https://gist.github.com/greg-hellings/5f8b38f12892260df14b4e512185048e
4: Converge config.yaml to config.iso: cloud-localds config.iso config.yaml
5: Boot VM: qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power8
-hda <qcow2 image> -cdrom config.iso
6: Login to the system with the username "vagrant" and password "vagrant".
That seems to get me into a system where I can login directly. I still
haven't figured out why SSH with password auth doesn't work, although
everything seems to indicate it should be. That should get you into the
latest Rawhide environment to see what's happening on that platform.
--Greg
On Sun, Jul 21, 2019 at 2:27 PM Greg Hellings <greg.hellings at gmail.com>
wrote:
>
>
> 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/20190819/7962bcbb/attachment-0001.html>
More information about the sword-devel
mailing list