Bug 24252 - old version
Summary: old version
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: libatlas (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Nobody's working on this, feel free to take it
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-10 04:29 MSD by Valery Pipin
Modified: 2010-10-28 00:13 MSD (History)
4 users (show)

See Also:


Attachments
лог ошибок (66.02 KB, application/octet-stream)
2010-10-26 22:59 MSD, Valery Pipin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valery Pipin 2010-10-10 04:29:50 MSD
пора бы обновить. Скорость линейной алгебры в numpy зависит от этого пакета.
В версиях > 3.9 поддерживаются фичи core-due и выше. Это есть в debian, ubuntu и gentoo
Comment 1 real@altlinux.org 2010-10-11 08:31:16 MSD
Вот тут:
http://sisyphus.ru/ru/srpm/Sisyphus/atlas/changelog
сказано, что последнее изменение было сделано роботом. Попытка обновления с таким изменением вылетает с руганью на прикладываемый патч, который был создан роботом. Надеюсь, этот робот знает, что делать дальше...
Comment 2 viy 2010-10-11 08:48:27 MSD
Евгений,
вы совысем совсем не подумавши баг повесили (ночью спать надо)
робот там не при чем, он пока патчи писать не умеет. 
Это старинный патч, его делал Алексей Турбин. 
то, что название atlas-3.7.11-alt6.qa1.patch,
это потому что в git rules и в спеке так написано.
а не прикладывается, потому что к старой версии написан...
Comment 3 viy 2010-10-11 08:50:11 MSD
я тоже, кстати. Это же не мой баг, почему я его открываю...
Comment 4 real@altlinux.org 2010-10-11 09:10:25 MSD
Извиняюсь, коли так.

И я не весил баг, я на него отвечал. Предварительно попробовав обновить...

Вообще, меня там не только патч, меня там и сам спек некоторым образом испугал. Так что взяться за обновление что-то нет желания (и так дел по горло).

А пакет висит на @nobody :(
А это очень плохо для такого важного пакета...
Comment 5 real@altlinux.org 2010-10-15 08:07:49 MSD
Похоже, желающих помочь не найдётся.

Попробую на выходных поковырять.
Comment 6 Valery Pipin 2010-10-15 08:37:28 MSD
> Похоже, желающих помочь не найдётся.
> 
> Попробую на выходных поковырять.
он собирается только вот в пакет запаковать хитрое дело.
Comment 7 real@altlinux.org 2010-10-15 08:45:16 MSD
У меня он пока застопорился на этапе make (т.е. патч я уже поправил и добавил вызов configure). В общем, пока дело двигается, но со скрипом, так что возиться буду наскоками, ибо полностью сесть и начать его ковырять непрерывно нет времени.
Comment 8 Repository Robot 2010-10-21 18:07:29 MSD
atlas-3.9.25-alt1 -> sisyphus:

* Thu Oct 21 2010 Eugeny A. Rostovtsev (REAL) <real at altlinux> 3.9.25-alt1
- Version 3.9.25 (ALT #24252)
Comment 9 Valery Pipin 2010-10-22 05:35:02 MSD
(In reply to comment #8)
> atlas-3.9.25-alt1 -> sisyphus:
> 
> * Thu Oct 21 2010 Eugeny A. Rostovtsev (REAL) <real at altlinux> 3.9.25-alt1
> - Version 3.9.25 (ALT #24252)

видимо надо и numpy с ней пересобрать, а то
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from numpy.linalg import *

In [2]: from numpy.random import *

In [3]: m=randn(2000,2000)

In [4]: %time U,s,V=svd(m)
Ошибка сегментирования
[vv@tao-vp ~]$
Comment 10 real@altlinux.org 2010-10-22 07:01:08 MSD
Не воспроизводится. Приаттачте какой-нибудь скрипт, попробую.
Comment 11 Valery Pipin 2010-10-22 08:07:44 MSD
(In reply to comment #10)
> Не воспроизводится. Приаттачте какой-нибудь скрипт, попробую.

На 64bit не воспроизводится?
Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
некоторые важные пакеты из x86_32. Может что то не дошло
Я обновил
libatlas+devel, liblapack+devel,liblaspack
Comment 12 real@altlinux.org 2010-10-22 08:52:10 MSD
"На 64bit не воспроизводится?"

Угу.

"Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
некоторые важные пакеты из x86_32"

А это уже другой вопрос. Сейчас идёт процесс массовой пересборки гигантского количества пакетов, поэтому лучше переджать, пока всё устаканится. А точечные апгрейды, вероятно, ещё больше всё усложняют.
Comment 13 Valery Pipin 2010-10-23 09:43:59 MSD
segmentation fault,
видимо из-за того что у меня  еще интел фортран.Я отключил переменные ifort в bash_profile. Так что с этой стороны все должно быть чисто. 
Вы бы не могли показать
результаты
from numpy.random import *
from numpy.linalg import *
m=randn(1000,1000)
%time U,s,V=svd(m)

у меня выдал LinAlgError: SVD did not converge. Сейчас попробую пересобрать libatlas под себя

> "На 64bit не воспроизводится?"
> 
> Угу.
> 
> "Возможно я не все библиотеки обновил, полный дист-апргрэйд у меня удаляет
> некоторые важные пакеты из x86_32"
> 
> А это уже другой вопрос. Сейчас идёт процесс массовой пересборки гигантского
> количества пакетов, поэтому лучше переджать, пока всё устаканится. А точечные
> апгрейды, вероятно, ещё больше всё усложняют.
Comment 14 Valery Pipin 2010-10-24 12:19:57 MSD
> "На 64bit не воспроизводится?"
> 
> Угу.
> 
Видимо системы разные:-)
Сейчас поставил обратно старую версию  и все работает.
А новый пакет у меня даже не собрался. Ладно подождем пока кто-нибудь из юзеров нарвется
Comment 15 real@altlinux.org 2010-10-25 08:38:46 MSD
In [1]: from numpy.random import *

In [2]: from numpy.linalg import *

In [3]: m=randn(1000,1000)

In [4]: %time U,s,V=svd(m)
CPU times: user 4.43 s, sys: 0.09 s, total: 4.52 s
Wall time: 4.52 s


"Видимо системы разные:-)"

Я ежедневно обновляюсь до сизифа.
Comment 16 Valery Pipin 2010-10-25 10:40:09 MSD
(In reply to comment #15)
> In [1]: from numpy.random import *
> 
> In [2]: from numpy.linalg import *
> 
> In [3]: m=randn(1000,1000)
> 
> In [4]: %time U,s,V=svd(m)
> CPU times: user 4.43 s, sys: 0.09 s, total: 4.52 s
> Wall time: 4.52 s
> 
> 
> "Видимо системы разные:-)"
> 
> Я ежедневно обновляюсь до сизифа.

Сегодня специально не пожалел времени и протестировал
на виртуальной машине sisyphus на i586, и x86_64
на первой ваш libatlas работает и показывает прекрасный результат
в виде 2.29 на этом тесте, на 64bit не работает, svd выдает диагностику что процесс не сходится, самое печальное для меня что eig не рабочий тоже.
Ну да ладно хорошо, что хоть у кого то работает.
Удачи!
Comment 17 real@altlinux.org 2010-10-25 12:09:47 MSD
Может быть, я всё же позволю дать совет (Вам необязательно ему следовать, но обычно он помогает): сделайте dist-upgrade. Если часть пакетов при этом вынесет, их всегда можно установить позже (одним днём весь сизиф не пересобрать).

В любом случае, точечные обновления, как не раз показывала практика, с лёгкостью ломают то, что до этого прекрасно работало.
Comment 18 Valery Pipin 2010-10-25 19:02:08 MSD
(In reply to comment #17)
> Может быть, я всё же позволю дать совет (Вам необязательно ему следовать, но
> обычно он помогает): сделайте dist-upgrade. Если часть пакетов при этом
> вынесет, их всегда можно установить позже (одним днём весь сизиф не
> пересобрать).
> 
> В любом случае, точечные обновления, как не раз показывала практика, с
> лёгкостью ломают то, что до этого прекрасно работало.
Я так и сделал. У меня стоит интел фортран локально. Для того чтобы исключить проблему интерференции, я использовал виртуальную машину на которой был сделан dist-upgrade. Я пробовал i586 и 64бит. В первом случае работает а во втором нет.
Процессор, интел core2 duo p8700. Кроме того, гарантированно работает старая версия пакета. Таким образом, врядли проблема состоит в моих локальных настройках. Предположения два: либо у вас локальные настройки, позволяющие держать две версии библиотек (это легко увидеть если посмотреть что использует нумпиевский lapack_lite.so), либо эта сборка не работает на моем процессоре,
Comment 19 real@altlinux.org 2010-10-26 06:58:42 MSD
Я на всякий случай пересоберу NumPy, SciPy, да и matplotlib заодно. Всё равно все пакеты, использующие ATLAS и/или LAPACK, пересобирать придётся.
Comment 20 real@altlinux.org 2010-10-26 07:14:31 MSD
Кстати, насчёт виртуальных машин, Вроде бы Вы ранее сообщали о нехватке памяти при работе с NumPy. Есть вероятность, что причины идентичны или каким-либо образом связаны.
Comment 21 Valery Pipin 2010-10-26 08:20:19 MSD
(In reply to comment #20)
> Кстати, насчёт виртуальных машин, Вроде бы Вы ранее сообщали о нехватке памяти
> при работе с NumPy. Есть вероятность, что причины идентичны или каким-либо
> образом связаны.
Было дело с виртуальной машиной на для i586. Тогда я памяти добавил и проблема ушла. Наверно я сумбурно объясняюсь, но чтобы небыло непоняток я подитожу мой опыт.
1)есть ноутбук - macbook pro5.5, cpu p8700 2.53Gz, 4G ram. На нем сизиф 64 бит, последний полный дистапгрэйд. Линейная алгебра не пашет, не сходятся ни eig ни svd. Я подозревал интерференцию с интел MKL. Однако, приэтом нет проблем со старой библиотекой (3.7)
2) Для исключения подозрений попробовал поставить сизиф с беты на виртуальной машине. Памяти ей дал > 2G. Имеем, на i586 все работает на 64 бит - нет.

Для полной проверки нужен чистый пример без питона, просто фортран и слинковать с atlas
Comment 22 real@altlinux.org 2010-10-26 08:35:02 MSD
"Для полной проверки нужен чистый пример без питона, просто фортран и слинковать
с atlas"

Жду :)
Comment 23 Valery Pipin 2010-10-26 22:59:07 MSD
Created attachment 4625 [details]
лог ошибок

автоматически создался при компиляции atlas
Comment 24 Valery Pipin 2010-10-26 23:04:42 MSD
Лог неудачной сборки приложен выше. Лог сборки rpm обрывается на
execstack -fPIC -m64 -fPIC -DDCPLX -DFindingJITCPCE -I./ /home/vv/RPM/BUILD/ATLAS/BUILD/..//src/blas/gemm/ATL_gemm.c
make[5]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/src/blas/gemm'
gcc -DL2SIZE=4194304 -I/home/vv/RPM/BUILD/ATLAS/BUILD/include -I/home/vv/RPM/BUILD/ATLAS/BUILD/..//include -I/home/vv/RPM/BUILD/ATLAS/BUILD/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_Core2 -DATL_CPUMHZ=2520  -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664 -DWALL -DATL_DYLIBS -DATL_NCPU=2 -DATL_TRUST_OMP -fomit-frame-pointer -mfpmath=sse -msse2 -O2 -g -Wa,--noexecstack -fPIC -m64 -fPIC -o xzdfindCE zdfindCE.o \
                   /home/vv/RPM/BUILD/ATLAS/BUILD/src/blas/gemm/ATL_zdFindCE_mm.o /home/vv/RPM/BUILD/ATLAS/BUILD/lib/libatlas.a -lpthread -lm
/home/vv/RPM/BUILD/ATLAS/BUILD/bin/ATLrun.sh /home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm xzdfindCE -f res/atlas_zdNKB.h
/home/vv/RPM/BUILD/ATLAS/BUILD/bin/ATLrun.sh: line 4:  2033 Segmentation fault      $atldir/$*
make[4]: *** [zdRunFindCE] Error 139
make[4]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm'
make[3]: *** [res/atlas_zdNKB.h] Error 2
make[3]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm'
make[2]: *** [/home/vv/RPM/BUILD/ATLAS/BUILD/tune/blas/gemm/res/atlas_zdNKB.h] Error 2
make[2]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
ERROR 843 DURING CACHE EDGE DETECTION!!.
make[2]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
cd /home/vv/RPM/BUILD/ATLAS/BUILD ; make error_report
make[3]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make -f Make.top error_report
make[4]: Entering directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
uname -a 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
gcc -v 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
Using built-in specs.
Target: x86_64-alt-linux
Configured with: ../configure --host=x86_64-alt-linux --build=x86_64-alt-linux --target=x86_64-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --program-suffix=-4.4 --with-slibdir=/lib64 --with-bugurl=http://bugzilla.altlinux.org --enable-bootstrap --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --enable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,java,ada --enable-java-awt=gtk --disable-plugin --with-native-libdir=/usr/lib64/gcj-4.4 --with-ecj-jar=/usr/share/java/ecj.jar --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.4-1.5.0.0/jre --enable-libgcj-multifile --disable-libjava-multilib --enable-java-maintainer-mode --with-arch_32=i586 --with-tune_32=generic
Thread model: posix
gcc version 4.4.5 20101001 (ALT Linux 4.4.5-alt1) (GCC) 
gcc -V 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
x86_64-alt-linux-gcc: '-V' option must have argument
make[4]: [error_report] Error 1 (ignored)
gcc --version 2>&1  >> bin/INSTALL_LOG/ERROR.LOG
tar cf error_HAMMER64SSE2.tar Make.inc bin/INSTALL_LOG/*
gzip --best error_HAMMER64SSE2.tar
mv error_HAMMER64SSE2.tar.gz error_HAMMER64SSE2.tgz
make[4]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make[3]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make[2]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD/bin'
Error report error_<ARCH>.tgz has been created in your top-level ATLAS
directory.  Be sure to include this file in any help request.
cat: ../../CONFIG/error.txt: No such file or directory
cat: ../../CONFIG/error.txt: No such file or directory
make[1]: *** [build] Error 255
make[1]: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
make: *** [build] Error 2
make: Leaving directory `/home/vv/RPM/BUILD/ATLAS/BUILD'
ошибка: Неверный код возврата из /home/vv/tmp/rpm-tmp.70936 (%build)


Ошибки сборки пакетов:
    Неверный код возврата из /home/vv/tmp/rpm-tmp.70936 (%build)


Зачем на 64 бит --with-arch_32=i586 --with-tune_32=generic??

Ошибка похоже исправлена (выделил ___) в версии 3.9.27:

ATLAS 3.9.27 released 10/20/10, changes from 3.9.26:
   * Fixed several bugs to allow L2 BLAS to install using a low-res timer
   * Fixed bug in x8664 kernel description causing seg faults for _____CGER_____
   * Fixed bug in r1hgen and r2hgen where first kernel's minM was ignored
   * Fixed bug in ATL_her/her2 where j-loop max was N rather than NN
   * Fixed bug so that h2gen.c generates ATL_GENGERK as a function that
     can handle all operations, not just least restricted kernel.
   * Fixed bug in ATL_syr & syr2 where nr computed incorrectly
   * Fixed cblas_[nrm2,asum,iamax,scal] so that they return with no
     operations if incX < 1 (this matches f77 behavior)
   * Fixed bug with extra spaces in configure's OSX libtool finding script
ATLAS 3.9.26 released 10/18/10, changes from 3.9.25:
   * Much improved GEMV & GER performance for x86-64:
     + Addition of SSE/x86-64 GER/GEMV generators
     + Complete rewrite of GEMV tuning infrastructure
     + Change to GER kernel API to minimize parameter passing
     + Arch defaults for Core264SSE3 & AMD64K10h64SSE3 updated
   * ANSI C code generators for MVT, MVN, R1 and R2.
     + should improve non-x86/x86-64 performance
   * Started rewrite of all L2BLAS:
     + GEMVT, GEMVN, GER, SYR, SYR2, HER, HER2 built from optimized kernels
     - TRMV, TRSV, SYMV, HEMV just call reference implementation
   * Bug fixes:
     + Fixed kernel testers & timers to correctly handle alignments,
       particularly ALIGNX2A.
   * Basic support for POWER7
     + VSX detection
     + VSX GEMM, GEMVN & GEMVT kernels provided by Mike Kistler of IBM
     + Arch defs
   * Fixed it so GEMM kernel files use $(GOODGCC) instead of flat gcc
     if 'gcc' is specified (so they inherit flags like -pg, -m64, etc).
Comment 25 Valery Pipin 2010-10-26 23:23:19 MSD
Пока не поздно...
Может быть для 6.0 лучше остаться на последней стабильной версии 3.8.3.
Нет гарантии, что выбранный релиз будет работать на новых процессорах
Comment 26 real@altlinux.org 2010-10-27 07:12:44 MSD
Последние сообщения - это Вы с кем говорили? Не со мной - явно :)

Я всё ещё жду ответа на #22.

PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках клиентских пакетов, так и людьми, которые с ним работают), обновлять его раньше появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности предельно стабильным...).
Comment 27 Valery Pipin 2010-10-27 07:38:22 MSD
У меня этот атлас не собирается, зачем тратить время на пример?
Эта сборка не рабочая со всех сторон на моем ноутбуке. Может проблема в процессоре или в памяти. Мне сейчас некогда с этим разбираться. Поставил на hold старую версию.
(In reply to comment #26)
> Последние сообщения - это Вы с кем говорили? Не со мной - явно :)
> 
> Я всё ещё жду ответа на #22.
> 
> PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках
> клиентских пакетов, так и людьми, которые с ним работают),
назовите пожалуйста архитектуру на которой тестировалась.
3.9.25 не везде может  работать. Смотрите чэнждлог от 3.9.27.
 
> обновлять его раньше
> появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности
> предельно стабильным...).

(In reply to comment #26)
> Последние сообщения - это Вы с кем говорили? Не со мной - явно :)
> 
> Я всё ещё жду ответа на #22.
> 
> PS. Нынешняя версия ATLAS в сизифе вполне стабильна (проверено как на сборках
> клиентских пакетов, так и людьми, которые с ним работают), обновлять его раньше
> появления бранча 6 не планирую (тут наоборот, нужно всё оставить по возможности
> предельно стабильным...).
Comment 28 real@altlinux.org 2010-10-27 08:15:35 MSD
"У меня этот атлас не собирается, зачем тратить время на пример?"

Этот - который в сизифе? Если да, зачем Вы его собираете?

"Эта сборка не рабочая со всех сторон на моем ноутбуке."

Этот - который в сизифе?

"назовите пожалуйста архитектуру на которой тестировалась. 3.9.25 не везде может  работать"

На i586 (точнее - Pentium4 c HT) и на x86_64. "Не везде" - это где?

"Зачем на 64 бит --with-arch_32=i586 --with-tune_32=generic??"

Это вообще откуда? В сизифной сборке нет ничего подобного.

"Смотрите чэнждлог от 3.9.27."

Предлагаете обновить? ;) Если нет, зачем эта версия вообще упоминалась?
Comment 29 real@altlinux.org 2010-10-27 08:31:15 MSD
И всё же я жду результаты (см. комментарий #22) с atlas из сизифа. Всё остальное здесь написанное не имеет к теме никакого отношения.

PS. Кстати, уже доступна версия 3.9.28. Можно будет на днях ещё раз обновить.
Comment 30 Valery Pipin 2010-10-27 08:56:06 MSD
(In reply to comment #29)
> И всё же я жду результаты (см. комментарий #22) с atlas из сизифа. Всё
> остальное здесь написанное не имеет к теме никакого отношения.
Это не просто. Потому как нужно тестировать для матриц большого размера.
Где-то больше 50x50. Пока ничего кроме диффузионного оператора с собственными занчениями в нулях функций Бесселя в голову не приходит. Для меньших матриц типа 2х2 и 3х3 вроде работает. Если у вас есть простой и доказательный пример, тогда я готов.
> 
> PS. Кстати, уже доступна версия 3.9.28. Можно будет на днях ещё раз обновить.

Мне честно говоря уже все равно, я считаю что в таких вещах лучше стабильность 
Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов --with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba atlas.spec
Comment 31 real@altlinux.org 2010-10-27 09:03:08 MSD
"Это не просто. Потому как нужно тестировать для матриц большого размера.
Где-то больше 50x50. Пока ничего кроме диффузионного оператора с собственными
занчениями в нулях функций Бесселя в голову не приходит."

Так за чем же дело встало?

"Если у вас есть простой и доказательный пример, тогда я готов."

Я не занимаюсь высшей математикой, я программист. А трясти своих коллег-кандидатов - это как-то неконструктивно, у них своя работа, и пока им обновление atlas никак не помешало. Поэтому я и жду примеров от заинтересованных людей (в данном случае - от Вас), раз Вы говорите, что что-то не работает, Вам и демонстрировать это неработу ;)
Comment 32 real@altlinux.org 2010-10-27 09:04:55 MSD
"Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов
--with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba
atlas.spec"

А в хэшере не пробовали?
Comment 33 Valery Pipin 2010-10-27 10:45:24 MSD
(In reply to comment #32)
> "Зупустил пересборку через rpm --rebuild  и вроде этих странных макросов
> --with-arch_32=i586 --with-tune_32=generic нет. Раньше собирал rpm -ba
> atlas.spec"
> 
> А в хэшере не пробовали?
Сейчас попробую,
rpm --rebuild закончился неудачей после где-то часовой компиляции
+ lib=libatlas
+ shift
+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined reference to `pthread_attr_setaffinity_np'
и т.д. до
libatlas.a(ATL_thread_tree.o): In function `ATL_thread_tree':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/pthreads/misc/ATL_thread_tree.c:84: undefined reference to `pthread_create'
collect2: ld returned 1 exit status
..
Меня еще мучают смутные сомнения насчет библиотек из x86_32? Это может влиять как то? На работу с  libatlas?
Comment 34 real@altlinux.org 2010-10-27 10:53:40 MSD
"+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o
libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
/home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined
reference to `pthread_attr_setaffinity_np'"

Похоже на то, что в новых версиях появилась зависимость от libpthread. Достаточно в команду линковки добавить -lpthread перед -lm, видимо. Хотя это только предположения, у меня сейчас как раз идёт процесс сборки 3.9.28.

"Меня еще мучают смутные сомнения насчет библиотек из x86_32? Это может влиять
как то? На работу с  libatlas?"

Не знаю. Я про biarch ничего не знаю и не использую (нет необходимости).
Comment 35 Valery Pipin 2010-10-27 11:13:59 MSD
(In reply to comment #34)
> "+ gcc -shared -Wl,--whole-archive libatlas.a -Wl,--no-whole-archive -o
> libatlas.so.3 -Wl,-soname=libatlas.so.3 -lm -Wl,-z,defs
> libatlas.a(ATL_thread_start.o): In function `ATL_thread_start':
> /home/vv/RPM/BUILD/ATLAS/BUILD/..//src/threads/ATL_thread_start.c:44: undefined
> reference to `pthread_attr_setaffinity_np'"
> 
> Похоже на то, что в новых версиях появилась зависимость от libpthread.
Я бьюсь над 3.9.25, src пакет взят из сизифа
Comment 36 real@altlinux.org 2010-10-27 11:26:34 MSD
"Я бьюсь над 3.9.25, src пакет взят из сизифа"

Зачем?
Comment 37 real@altlinux.org 2010-10-27 11:29:20 MSD
Вам лучше взять репозиторий с git.alt:/people/real/packages/atlas.git и пробовать собирать оттуда.
Comment 38 Valery Pipin 2010-10-28 00:13:35 MSD
(In reply to comment #37)
> Вам лучше взять репозиторий с git.alt:/people/real/packages/atlas.git и
> пробовать собирать оттуда.
Долгая история, я уже забыл свой username. :-)
В хашере сборка прошла чисто и быстро. Я собирал 3.9.25. после установки  тест с svd работает. Однако время исполнения теста больше чем в 3.7, а я ожидал прироста производительности где-то в 1.5-2 раза, кроме того результаты  eig на моих кодах не являются правильными. Что ж, придется сделать тестовый пример.