Skip to content
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

PPC64le: Make fails on Jellyfish. Need --without-sse #94

Open
jlost opened this issue Jul 14, 2016 · 3 comments · May be fixed by #110
Open

PPC64le: Make fails on Jellyfish. Need --without-sse #94

jlost opened this issue Jul 14, 2016 · 3 comments · May be fixed by #110

Comments

@jlost
Copy link

jlost commented Jul 14, 2016

I'm trying to get Sailfish to work on an IBM POWER8 system (PPC64le RedHat). Sailfish fails during make due to SSE-specific instructions in Jellyfish. Tackling the Jellyfish issue (gmarcais/Jellyfish#63) separately, one workaround was to configure Jellyfish with: --without-sse.

Alter the CMake script to check for SSE on its own and provide the necessary flag, or provide a flag for an existing Jellyfish installation. The end result should be that sailfish is able to pass this particular build step when building on PPC64le, either automatically or by specifying an external Jellyfish installation.

@jlost jlost changed the title Fails make on Jellyfish: need --without-sse PPC64le: Make fails on Jellyfish. Need --without-sse Jul 27, 2016
Millak added a commit to Millak/sailfish that referenced this issue Sep 4, 2018
@Millak Millak linked a pull request Sep 4, 2018 that will close this issue
@Millak
Copy link

Millak commented Sep 4, 2018

Somewhere between jellyfish-2.2.3 and 2.2.10 jellyfish was patched. This fix neither adds a check for SSE nor allows for an existing jellyfish installation, but it does fix the compiling. If jellyfish must remain at 2.2.3 I can prepare a different fix.

@rafaeldelucena
Copy link

rafaeldelucena commented Jun 19, 2019

@jlost this was already fixed, right?

@jlost
Copy link
Author

jlost commented Nov 20, 2023

It looks like #110 would fix it, but I no longer have access to the hardware to verify. At any rate, updating patch versions of libraries is usually a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants