New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial PowerPC 32bit support #6108

Merged
merged 5 commits into from Jan 19, 2019

Conversation

Projects
None yet
3 participants
@stenstorp
Copy link
Contributor

stenstorp commented Dec 22, 2018

[Had to redo the PR after mangling some pushes to fix some conflicts with new updates, sorry]
[Original PR: https://github.com//pull/5861 ]
These changes allow for the base-chroot{-musl}, base-system, base-devel and linux packages to be built for 32 bit PowerPC; both glibc and musl targets.
This is just the bare minimum for building the cross-powerpc-linux-* packages.
I have avoided using ppc*) in most cases as ppc64{le} will likely use different options.
These are not all the required changes to build every package for ppc as that will take a long time and I thought it would be better to get basic support done first. I will be contributing fixes for other packages soon though.
Please let me know if anything needs changing/packages need revving, I sometimes forget that :)

@q66

This comment has been minimized.

Copy link
Contributor

q66 commented Dec 22, 2018

you probably don't/shouldn't need to be doing all those revbumps, since the changes don't change anything for non-ppc systems, merely enabling the ppc ones.

@q66

This comment has been minimized.

Copy link
Contributor

q66 commented Dec 22, 2018

also, fetch your autoconf cache files from http://cgit.openembedded.org/openembedded-core/tree/meta/site

@stenstorp stenstorp force-pushed the stenstorp:ppcbe branch from 8eea35c to 6644228 Dec 22, 2018

+# if definded(__GLIBC__)
powerpc-linux-gnu
+# else
+ powerpc-linux-musl

This comment has been minimized.

@q66

q66 Dec 23, 2018

Contributor

why is this patch necessary? none of the musl packages we have already define a python platform triplet; they all use the default GNU triplet and it doesn't seem to harm anything. And for example Adelie Linux, a distro that purely uses musl and has support for powerpc, doesn't patch the triplet either.

This comment has been minimized.

@stenstorp

stenstorp Dec 23, 2018

Contributor

Without it, python doesn't recognise the powerpc-linux-musl triplet; says it's not a valid target. I'm not aware of how Adelie Linux does it, perhaps they do other things differently too.

This comment has been minimized.

@q66

q66 Dec 23, 2018

Contributor

Why does it need to? On powerpc64-linux-musl as well as powerpc64le-linux-musl, it compiles just fine (cross and normal), all the triplets inside the python package are powerpc64(le)-linux-gnu, but that is also the case for musl builds for x86_64, aarch64 and arm, and they work fine.

This comment has been minimized.

@q66

q66 Dec 23, 2018

Contributor

to demonstrate, here is what i get when i unpack the python3 package for armv6l-musl

$ find . -name '*.so'|xargs file       
./usr/lib/libpython3.so:                                                                ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
./usr/lib/libpython3.6m.so:                                                             symbolic link to libpython3.6m.so.1.0
./usr/lib/python3.6/lib-dynload/_sha512.cpython-36m-arm-linux-gnueabihf.so:             ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
./usr/lib/python3.6/lib-dynload/_multibytecodec.cpython-36m-arm-linux-gnueabihf.so:     ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
./usr/lib/python3.6/lib-dynload/readline.cpython-36m-arm-linux-gnueabihf.so:            ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
./usr/lib/python3.6/lib-dynload/_md5.cpython-36m-arm-linux-gnueabihf.so:                ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped
... and so on ...

This comment has been minimized.

@stenstorp

stenstorp Dec 23, 2018

Contributor

I don't know. It doesn't pass the configuration without it on ppc-musl.

This comment has been minimized.

@Hoshpak

Hoshpak Jan 17, 2019

Member

Sounds good. @stenstorp could you please create smaller PRs so we can get the minimal basics reviewed and merged first?

This comment has been minimized.

@stenstorp

stenstorp Jan 17, 2019

Contributor

Sure, what stuff do you not want in this PR? This is fairly minimal, only enough to get the base-* packages built and the kernel.

This comment has been minimized.

@Hoshpak

Hoshpak Jan 17, 2019

Member

let's start with the minimum changes that are necessary to add the architecture and cross-compile a simple package that is not restricted to a specific architecture.

This comment has been minimized.

@q66

q66 Jan 17, 2019

Contributor

Yes, basically the changes in common/ + cross-vpkg-dummy + cross-powerpc-*. Once that is done, we could move on to libc, then stuff necessary for bootstrap, then the rest.

This comment has been minimized.

@stenstorp

stenstorp Jan 17, 2019

Contributor

Done, only the stuff in common, cross-vpkg-dummy and cross-powerpc-*.

@stenstorp stenstorp force-pushed the stenstorp:ppcbe branch from 6644228 to 248a889 Jan 6, 2019

@stenstorp

This comment has been minimized.

Copy link
Contributor

stenstorp commented Jan 6, 2019

Fixed conflicts with #6417

@stenstorp stenstorp force-pushed the stenstorp:ppcbe branch 6 times, most recently from 0b24585 to 198ea09 Jan 6, 2019

@stenstorp stenstorp force-pushed the stenstorp:ppcbe branch 2 times, most recently from b147150 to 37fa1d2 Jan 17, 2019

@q66

This comment has been minimized.

Copy link
Contributor

q66 commented Jan 18, 2019

Generally looks good to me. But please, do handle your cross toolchain patches as symlinks, same as every other cross toolchain does, instead of just directly copying the files in.

@Hoshpak

This comment has been minimized.

Copy link
Member

Hoshpak commented Jan 18, 2019

Please adjust the commit message for new packages, it should be New package: <pkgname>-<version>. Otherwise it looks good to me.

@q66

This comment has been minimized.

Copy link
Contributor

q66 commented Jan 18, 2019

You might also want to -mtune for a specific CPU, something you think will be common, to get better performance on these. For example, my ppc64le builds are set for powerpc64le generic -mcpu (i.e. POWER8+) but have tuning for power9, the ppc64 builds are for 970 (i.e. G5/970 baseline) but also tuned for power9. It's probably unwise to specify -maltivec for 32-bit ppc (I specify it on 64-bit, as the 970 has altivec and virtually everything it will run on does too, on 32-bit the situation is different), so I'd leave that as it is, but we could benefit from less generic flags. That is just a suggestion though, I'm not familiar enough with 32-bit ppc to make a solid assessment.

@stenstorp

This comment has been minimized.

Copy link
Contributor

stenstorp commented Jan 18, 2019

I don't want to be too aggressive with the mcpu/mtune stuff as I don't want to gimp G3/PS3/Wii etc.
I'll leave off altivec as only the G4s have it.

@stenstorp stenstorp force-pushed the stenstorp:ppcbe branch from 37fa1d2 to 344c4fe Jan 18, 2019

@Hoshpak Hoshpak merged commit 7df20b2 into void-linux:master Jan 19, 2019

1 check failed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details

@stenstorp stenstorp deleted the stenstorp:ppcbe branch Jan 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment