-
Notifications
You must be signed in to change notification settings - Fork 80
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
SEACAS (Spack) hidden blas/lapack dependency #307
Comments
Very strange -- It is indicating that
These symbols don't appear in any of the files that are included in libsuplib as best I can tell... If they can be resolved from blas or lapack, then my guess is that they are being resolved incorrectly, so not sure if that is a good solution and may be instead hiding the problem... I will see if I can figure out where this is coming from.... Somehow the fortran compiler seems to be doing this somehow... |
Is it possible to query the |
Let me check and see. I did Let me get on that machine and dig a little. I do not think this is really a bug in SEACAS, but I also wasn't able to trigger it anywhere else =\ |
SEACAS can be built without metis, so would be interesting to see if metis is truly where this is coming from. Confusing that it says the undefined references are from libsuplib.so.2.0 since that has no dependence at all on metis... |
Not metis/parmetis. Weird, grepping all the libs I have from my spack build,
I wonder if cray fortran is doing some kind of optimization and promoting code to a libsci function? |
Yes, that was my only thought -- cray fortran optimizer changing a loop into a blas call... Seems like if it could do that it would also add the dependency, but maybe that is getting lost somewhere... |
@jjellio Is this still an issue, or did it get solved outside of here... |
It's not really solved. The grief happens if you unwrap Cray PE, and use CrayFTN directly w/optimizations turned on (O2/O3 seemed to do it). The result is, Cray Fortran transformed a region into a BLAS call, expecting Cray libsci to be on the command line (I'm guessing their PE simply falls over when the wrapper stuff is taken away - hence it doesn't know what to do). -- Edit add: It's spack that is yanking Cray's fortran compiler outside It's really a SPACK thing - spack also removes libsci (explicitly) when you use Cray's wrappers - it only adds the libsci information back to the ENV if the package actually specifies a blas/lapack dependency... So, this is probably a spack specific issue (but it may arise again ... spack is trying to completely unwrap Cray, so maybe this will be become more prevalent.) Maybe we just close this - and atleast someone can search github if pops up? Edit add: using the Cray Fortran flag |
OK. Could also possibly add either a blas dependency or the |
My view - is there is zero wrong with your Spack package or SEACAS. I added a lapack dependency (and use libsci) in spack - but that just let's me work around it. If someone did CrayFTN via spack - but had blas marked something besides libsci, I'm guessing they would hit some archaic build error that makes little sense. I seem to be the only one that's hit this, but SPACK is trying to unwrap Cray even more (so maybe this will happen more often). I guess you could
|
Yes, all good suggestions. Maybe best at this time is to just leave it as is and reopen if it happens again... Which it probably will... I think (2) is probably the best solution for SEACAS since the added optimization to a blas routine probably saves a millisecond at most... I will add that to my "do when you have a few minutes to burn" queueu. |
Stale issue message |
I'm not sure where to report this - it's probably a spack issue - but it's manifesting with SEACAS' install.
Effectively, a package seacas is using is depending on lapack/blas to find
_idmax_
and_idmin_
. I suspect metis or parmetis. The error likely shows up, because I've built those packages statically, so they aren't able to silently RPATH in the required lib. Add to it, if built inside trilinos, lapack/blas are typically on the link lines anyway (so this could be an actual seacas or zoltan dependency? a quick grep says no).The spack line is:
The quick fix was to add
depends_on('lapack')
to the seacas package (when+metis
). I'm not too familiar with SEACAS outside Trilinos - and I'm afriad posting this directly to spack will have it lost in the weeds rather fast.The text was updated successfully, but these errors were encountered: