Date: Sat, 24 Jun 2023 04:13:47 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: maintainer-feedback requested: [Bug 272173] graphics/opencv ATLAS knob cannot depend on cblas and cmake cannot find lapacke for this knob Message-ID: <bug-272173-39348-CPzND9eUFj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272173-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-272173-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Bugzilla Automation <bugzilla@FreeBSD.org> has asked freebsd-desktop (Team) <desktop@FreeBSD.org> for maintainer-feedback: Bug 272173: graphics/opencv ATLAS knob cannot depend on cblas and cmake can= not find lapacke for this knob https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272173 --- Description --- maybe fallout from my 13.2 update that I lost track of, but I thought I had this package while trying to get blender installed. Anyway, noticed cblas a= nd atlas-math cannot coexist, cblas says things are broken, they clobber. after clearing this depend and checking the configure's output I noticed lapack wasn't being found, actually lapacke, so had to force its path using a CMAK= E_ON with Atlas_CLAPACK_INCLUDE_DIR. opencv now builds with the ATLAS blas option selected.=20 Its possible openblas maybe has this issue? not sure, worth a quick check, = but I have no easy way to do that at the moment. it would def be using a differ= ent cmake variable though. maybe the openblas cmake routines check /usr/local/include/lapacke by default though too. the variable would seemin= gly be OpenBLAS_INCLUDE_DIR based on the OpenCVFindLAPACK.cmake routines that d= on't include the full path that was tripping up the Atlas routines in the same f= ile.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272173-39348-CPzND9eUFj>