bug#63986: Julia is very slow

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hi,

Efraim Flashner <efraim@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’.