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.

Sign up for GitHub

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

Jump to bottom

openblas: Fix build issue when inside VM and CPU is undetected #21016

Closed
wants to merge 1 commit into from
Closed

openblas: Fix build issue when inside VM and CPU is undetected #21016

wants to merge 1 commit into from

Conversation

knedlsepp
Copy link
Member

Motivation for this change

Trying to build openblas inside a virtual machine leads an undetected CPU and a build failure.
I circumvent this the same way it is done in the OpenBLAS .travis.yml: https://github.com/xianyi/OpenBLAS/blob/master/.travis.yml and set the TARGET flag to NEHALEM. It is odd that we have to do this even though DYNAMIC_ARCH is set. That is why I opened an issue upstream:
OpenMathLib/OpenBLAS#1027

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

openblas: Fix build issue when inside VM and CPU is undetected
e761122 
The local build of openblas fails when the CPU is not detected. This
happens even though the DYNAMIC_ARCH flag is set. We circumvent this the
same way it is done in the OpenBLAS .travis.yml
https://github.com/xianyi/OpenBLAS/blob/master/.travis.yml
and set both the DYNAMIC_ARCH and the TARGET flag.
I opened an issue upstream:
OpenMathLib/OpenBLAS#1027
@mention-bot
Copy link

@knedlsepp, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ttuegel, @FPtje and @adnelson to be potential reviewers.

@FPtje
Copy link
Contributor

FPtje commented Dec 9, 2016

I wouldn't just set an arbitrary target in the global flags. Note how the target is already set in the local flags below your change.

@knedlsepp
Copy link
Member Author

knedlsepp commented Dec 9, 2016 •
edited

As far as I understood the DYNAMIC_ARCH flag should yield binaries for all targets anyway, so I don't really understand why I need to pass that flag. However without the flag I get a build error and the build travis-file in the openblas repository also uses the same approach, so while not pretty it seems a reasonable fix to me. On the other hand it seems to me as a kind of impurity if the build depends on the cpu-microarchitecture and we want to get rid of those impurities.

@ttuegel
Copy link
Member

ttuegel commented Dec 9, 2016

I want to hold on this for the moment until there is more information from upstream. You're right: there should be no need to set TARGET if we're using DYNAMIC_ARCH. However, if we're going to set TARGET, it needs to be something much older than nehalem. I suspect the build system is using TARGET to detect architecture (DYNAMIC_ARCH should really be called DYNAMIC_MICROARCH). If that's the case, there will be no harm in setting TARGET to some older x86-64 variant.

@ttuegel
Copy link
Member

ttuegel commented Dec 11, 2016

Thanks for bringing this issue to my attention! I refactored the Nix expression in #21055 so that TARGET is always set, which should fix the issue you encountered.

@ttuegel ttuegel closed this Dec 11, 2016
@knedlsepp knedlsepp deleted the fix-openblas-build branch December 28, 2016 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@knedlsepp @mention-bot @FPtje @ttuegel