Hi, Efraim Flashner <efr...@flashner.co.il> skribis:
> On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote: [...] >> > >> > /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so: >> > undefined symbol: dsfrk_64_ >> >> The ‘_64’ suffix is added by a patch in this very series, that adds >> ‘SYMBOLSUFFIX=64_’ to ‘openblas-ilp64’. >> >> I don’t know what the rationale was for that configuration change, but >> this is a good area of investigation. >> >> Efraim, WDYT? > > the SYMBOLSUFFIX change seems to be standard across other distributions, > and in fact there seem to be packages out there which rely on it > directly. > > Looking at this error specifically and also the pcre2-8 errors we get > during the 'test phase for julia, it seems the suggested fix is to build > those libraries with julia. So we'd want to replace the pcre2 and the > lapack libraries in the julia sources (for pcre2 for all the > architectures, for lapack for x86_64 specifically) and let julia build > and link to them during the build phase. That would seem like a step backwards though, no? Usually we prefer to unbundle things. Actually, why does liblapack.so end up in Julia itself, as opposed to just linking to libopenblas.so? Ludo’.
