Re: Issue with eselect-ldso -> flexiblas migration

On 2026-03-16 10:36:32, Poncho wrote:
> 
> Now why is this a gentoo issue?
> 
> If set the useflag
> */* -flexiblas eselect-ldso
> and update the system and reemerge scipy gsl goldencheetah everything 
> works as expected. So it is a regression related to the eselect-ldso -> 
> flexiblas migration
> 
> I've never configured anything related to blas/flexiblas on my system. 
> It just used to work.

While it should not crash in any case, there is a chance that the
upgrade switched your default blas from the netlib reference
implementation to openblas, and that this is responsible for the
crash.

What does /etc/flexiblasrc say? If it's default = openblas, try
changing it to default = netlib. (You can also use the "flexiblas"
command to modify this file.)


> > Thread 58 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7f4558df36c0 (LWP 338040)]
> > 0x0000000000000000 in ?? ()
> > (gdb) bt
> > #0  0x0000000000000000 in ??? ()
> > #1  0x00007f4538ddc18f in ??? () at /usr/lib/python3.13/site-packages/scipy/linalg/_flapack.cpython-313-x86_64-linux-gnu.so

If the solution doesn't turn out to be easy (like switching from
openblas to netlib), we may need the missing symbols from that
backtrace. There are some good tips on

  https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces

but a quick summary would be to set,

  USE=debug
  CFLAGS="-Og -fno-omit-frame-pointer -ggdb"
  CXXFLAGS=$CFLAGS
  FEATURES="nostrip"

and then re-emerge the relevant packages -- whichever ones you think
the crash might have happened in. The next time it crashes the
backtrace will hopefully contain the exact function and line that it
crashed on.