bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63986: Julia is very slow


From: Ludovic Courtès
Subject: bug#63986: Julia is very slow
Date: Fri, 29 Sep 2023 10:46:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]