[sword-devel] ppc64le build errors

Greg Hellings greg.hellings at gmail.com
Mon Feb 17 12:58:19 EST 2020


I should also note that "br=virbr0" is specific to my machine and is the
networking bridge where all my local VMs are attached. I don't know where
it came from, but your machine might have a different network attachment.

--Greg

On Mon, Feb 17, 2020 at 11:57 AM Greg Hellings <greg.hellings at gmail.com>
wrote:

> It's been some months since build errors on the PPC64LE architecture in
> Fedora cropped up. The errors all seem to be around the definition of
> certain certain integer variable types and crop up like this[0].
>
> Currently I'm building with this patch[1], provided by Jaak, to avoid the
> problem. It switches out use of __u16, __s64, etc for std::uint_16t and the
> like. However, as it is not considered best practice to maintain lots of
> patches downstream as that foists work upon everyone else who wants to
> package, I had requested Troy look at this. But, obviously, working with
> PPC64LE Is not something we do in our daily work much.
>
> Recent developments in Fedora and my own Googling have made this a bit
> more accessible, if you have time to look into the build errors, Troy. I've
> just been able to launch a ppc64le VM on my local machine with the
> following steps:
>
> 0) Download the pre-packaged qcow2 image from the Fedora servers:
> http://mirrors.kernel.org/fedora-secondary/development/32/Cloud/ppc64le/images/
> 0.0) I suggest making a copy, in case something goes awry, then you have
> the pristine image to boot from, so I just do "cp Fedora-Cloud<blah>.qcow2
> fedora-32.qcow2" and then can restore from the downloaded if I need to
> 1) Install qemu-system-ppc64 and cloud-utils on your local host (at least
> that's the package names in Fedora)
> 2) Write out this cloud-init file[2] to the same directory where you
> downloaded the Fedora image with the filename "user-data" (the file has
> more than is bare minimum necessary)
> 3) Generate the cloud-init ISO file by running "cloud-localds config.iso
> user-data"
> 4) Boot the system with this command:
> qemu-system-ppc64 -machine pseries -cpu power8 -nodefaults -nographic
> -serial stdio -hda fedora-32.qcow2 -netdev bridge,br=virbr0,id=net0 -device
> virtio-net-pci,netdev=net0 -cdrom config.iso -m 2048
>
> The resulting machine is slow but functional (you can increase the RAM by
> increasing the "2048" at the end, and you can probably enable
> multi-processing if you really want to but I haven't toyed with it). It can
> sometimes take as much as 10 minutes to fully boot, sometimes it's up in 90
> seconds on my relatively modern i7 laptop. From the command line you can
> install the necessary tools, just like you would on any other Fedora VM
> (sudo dnf install make cmake libcurl-devel libicu-devel gcc-c++)
>
> The "-cdrom config.iso" argument is only necessary on the first boot to
> setup login, which will be username "vagrant" and password "vagrant" as
> specified in the user-data file.
>
> I would like to streamline this for you, but I have a mountain of things
> on my plate and I don't know if I'll get to it in a reasonable amount of
> time. Meanwhile, these new-ish qcow2 images that are coming from the Fedora
> folk make it very reasonable to get a local VM booted for test purposes.
>
> Hopefully this gives you the platform to figure out what's going on in
> ppc64le land and maybe work up a mainline patch before we get to the 1.9
> series.
>
> -Greg
>
> [0] https://gist.github.com/greg-hellings/a6756fdf6081038fe97569f74a28f00e
> [1]
> https://src.fedoraproject.org/rpms/sword/blob/master/f/sword-1.8.1-integer-types.diff
> [2] https://gist.github.com/greg-hellings/9a9dca49c7fe62311f7f7232e7da1278
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20200217/fc1e3895/attachment.html>


More information about the sword-devel mailing list