-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
work around OpenBLAS inability to correctly detect CPU #13842
Comments
Which CPU do you have? |
What exactly are the error messages. Unless you have a brand new skylake and haven't built 0.2.15 since we started using it, this might be something different. The only thing we can do differently about this is re-implement openblas with llvm calls. |
I just had an OpenBLAS error as well that looked like an architecture misdetect, but cleaning and rebuilding fixed it, so I assume it was just some stale state from getting an updated version. @StefanKarpinski did this happen just after updating OpenBLAS? |
We even give an exact error message here telling you to do |
This happens on fresh clones. The error message is excellent but not having the error in the first place is better. You used to reliably clone Julia and run make and get a working system. Have we given up on that ideal? |
|
This now happens on multiple different systems: iMac from 2011 and my MacBook from this year. Will post cpu details when I'm back home at the end of the week. The newer machine is somewhat understandable but the older machine used to work so this is regression. |
Have you upgraded software or toolchain recently? Sounds like #13836 or a similar local misconfiguration, otherwise this would be reported more often. Need full logs of output to say anything conclusive. |
I'm seeing the same issue consistently of late on both on OSX 10.8 (MacBookPro10,2 ; Intel Core i7) and a Linux server (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz) when following the build instructions here https://github.com/JuliaLang/julia with a fresh clone. Want the make logs as an attachment or is a gist preferable? |
gist please. much easier to look through when on mobile, can stay in browser |
Here's the gist: https://gist.github.com/d607ada268ddba9e696e I had to run make a number of times to get to the openblas error. The gist contains the full output of the various make commands. The system details are
|
Looks like #7653 ? binutils too old? |
And it's in README btw https://github.com/julialang/julia#linux-build-troubleshooting |
Yes, a workaround is documented, thanks. This issue has to do with avoiding the need for the workaround . To quote from the initial report: "... this has been going on for a long time now. Can we work around this somehow so that people building Julia from source have a better experience?" |
Actually we're supposed to require gcc 4.7 to build Julia itself. At least that's what README.md says, and while it works without it for now, it should stop soon when porting to a newer LLVM. |
We can implement #9372. Note that when we upgrade LLVM it will no longer be possible to build Julia with gcc older than 4.7 anyway. If you're on NERSC, can't you get a newer toolchain via some |
Sure, I can easily try another compile from a clean install using gcc-4.7, On Wed, Nov 18, 2015 at 1:52 AM, Tony Kelman [email protected]
|
Technically it's the binutils version that should matter here. So check that first, via |
Good that you mentioned this. The NERSC binutils module is old (GNU On Wed, Nov 18, 2015 at 10:32 AM, Tony Kelman [email protected]
|
No openblas error this time with (new) binutils ((GNU Binutils) 2.25) and gcc-4.8.1 and a fresh clone. As an aside, and totally unrelated I think, I saw quite a few other failures which were "fixable" by simply rerunning make: make[1]: *** [/scratch/copeland/julia/deps/srccache/libuv/configure] Error 129 and all due to variations on this warning: Remote branch v0.2.15 not found in upstream origin, using HEAD instead |
Not positive, but those might be due to your old git version. We used to require 1.7.3 or newer for Pkg, but the makefiles might be using newer features now. @StefanKarpinski you were OP here, can you update what was happening on your machine? |
I'll update git and redo to confirm. On Thu, Nov 19, 2015 at 3:16 AM, Tony Kelman [email protected]
|
Thanks for the good advice. Using the following tool versions, I got a clean (though long) make with no openblas problems for release-0.4 on Xeon(R) CPU E5-2670 0 @ 2.60GHz (Sandy bridge) / Linux 2.6.32. Updating the Platform specific build notes @ https://github.com/JuliaLang/julia would be very helpful for newcomers.
|
Thanks for the report. Would you like to take a crack at incorporating what you learned via a pull request? |
Sure, I'll give it a try. On Thu, Nov 19, 2015 at 12:01 PM, Tony Kelman [email protected]
|
Since this bug is still open, here is another openblas error report on the dell latitude 7480 with an Intel Core i7-7600U CPU built on zesty (ubuntu 17.04) released last week, https://gist.github.com/svaksha/cc30047982e9b603e1a27d99eedcf703 I tried to build Julia with : [1] the latest unstable version of Julia - commit ceccddf, and [2] the last stable version of Julia - release-0.5 When both failed with the openblas error, I tried building it by running 'make -C deps clean-openblas', 'make OPENBLAS_USE_THREAD=0' and 'make OPENBLAS_TARGET_ARCH=NEHALEM'. No luck. |
I believe this hasn't been seen for a while now. Please reopen if still an issue. |
It's gotten to the point where every time I build Julia from scratch, building OpenBLAS fails. For a while, I had hoped that OpenBLAS's hardware detection might get better, but this has been going on for a long time now. Can we work around this somehow so that people building Julia from source have a better experience?
The text was updated successfully, but these errors were encountered: