ppc64le support

[sumitd2]

Tested locally.
cc: @seth-priya

[sumitd2]

@kleisauke thanks for your input. I figured both of them out, plus another one. Working on the build failure, do you have any suggestions there?

[kleisauke]

@sumitd2 I just opened PR #243 to fix these build failures.

[lovell]

@sumitd2 Thank you very much for this PR, please can you rebase against the main branch to pick up the fixes for the (unrelated) build failures.

[sumitd2]

@lovell done

[sumitd2]

@lovell @kleisauke darwin-x64 failed

[sumitd2]

@lovell @kleisauke I am not sure how the npm/linux-ppc* directory should be named. js returns the arch as ppc64, not ppc64le.

[lovell]

I am not sure how the npm/linux-ppc* directory should be named. js returns the arch as ppc64, not ppc64le.

Good question. Node.js (and therefore npm) appears to use the endian-less ppc64 for the platform value.

What is the output of node -p "process.arch" on a ppc64le machine you're hoping to use?

[sumitd2]

node -p "process.arch"

[root@sumit-rhel ~]# node -p "process.arch"
ppc64

[sumitd2]

@lovell @kleisauke The problem is here:
https://github.com/sumitd2/sharp-libvips/blob/8d2f34914f24cd36421e8b3b4baa8f08cfba9cf6/npm/populate.sh#L9

[kleisauke]

@sumitd2 That line shouldn't cause issues for linux-ppc64le, it only does the following substitutions:
darwin-arm64v8 -> darwin-arm64
linux-arm64v8 -> linux-arm64
linux-armv6 -> linux-arm
linuxmusl-arm64v8 -> linuxmusl-arm64

But indeed, we should probably also strip the le suffix there to match the endian-less npm package naming convention:
linux-ppc64le -> linux-ppc64

[sumitd2]

But indeed, we should probably also strip the le suffix there to match the endian-less npm package naming convention: linux-ppc64le -> linux-ppc64

@kleisauke Yes, that's what I meant. I am planning to check if the variable contains the suffix "ppc64le" and strip the last two characters, unless you have a better solution.

[sumitd2]

@kleisauke I have updated populate.sh, can you trigger the build? Also, when do you plan publish it to the npm registry? My next task is to port lovell/sharp to Power, so I assume libvips will be needed in the registry.

[lovell]

Thanks for the updates, I'm planning to rename some of the platform subdirectory names to match those under npm as a precursor to #206 anyway.

The next time this is published to npm will be as part of the next release of libvips, and yes, after that's done we'll need to do the other half of this task for prebuilt sharp binaries too.

I can't say when, but perhaps you could subscribe/watch for new releases.

[lovell]

@sumitd2 The @img/sharp-libvips-linux-ppc64 package is now published. If you're still interested, this means that the next step of adding prebuilt sharp binaries can now be considered, thank you.