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.helli...@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 >
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
