Package Details: atlas-lapack 3.10.3-1

Git Clone URL: (read-only)
Package Base: atlas-lapack
Description: Complete LAPACK and BLAS implementation using optimised ATLAS routines
Upstream URL:
Licenses: custom:blas, custom:lapack, custom:atlas
Conflicts: atlas-lapack-base, blas, cblas, lapack
Provides: atlas-lapack-base, blas, cblas, lapack=3.6.1
Submitter: ilpianista
Maintainer: giniu
Last Packager: giniu
Votes: 91
Popularity: 0.575738
First Submitted: 2008-04-24 01:36
Last Updated: 2016-07-30 16:48

Required by (243)

Sources (6)

Latest Comments

deltaecho commented on 2018-04-26 22:40

The best solution is to recompile numpy after replacing BLAS (no hacking required): yaourt -Sb python-numpy # be sure to add python-numpy to the IgnorePkg attribute of your /etc/pacman.conf to avoid breaking updates; you will need to compile it from source from here-on-out, which is easy to do

greyltc commented on 2018-03-03 22:35

Since this package provides and conflicts with cblas, I think it should at least install all the shared objects that the cblas packages does. /usr/lib/ and /usr/lib/ are missing here.

Notably, the missing /usr/lib/ breaks python's numpy module!

marcin commented on 2017-11-14 07:12

Cant compile due to CPU throttling enabled.

Followed instructions provided by @phcerdan on 2017-06-08 06:48 to disable it, and it worked. Could compile the package. Thanks @phcerdan

mullah commented on 2017-09-22 18:32

I also had to symlink to It seems that references instead of, the relevant error message being:
/usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/, not found

hicarus commented on 2017-08-26 07:23

I have same issue as @EpsilonDelta

EpsilonDelta commented on 2017-08-12 05:52

There seems to be an issue where numpy is looking for but it cannot find it. numpy works after symlinking to but i'm not sure if that's a real fix. Is this package supposed to com with is different than

jerryjiahaha commented on 2017-06-21 18:12

After disabling intel_pstate and setting performance, my `scaling_cur_freq` is still always smaller than `cpuinfo_max_freq` and configure failed at checking cpu throttle.
Solution: `echo 1 > /sys/module/processor/parameters/ignore_ppc` Then set `/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq` works for me.


p.s. I think my broadwell cpu (with model 0x3D) should be checked as IntCorei3 in CONFIG/src/backend/archinfo_x86.c (At present it will be checked as MACHOther)

phcerdan commented on 2017-06-08 06:48

Hey I just installed, and make these notes, that might be useful for somebody else:
Good explanation in atlas site:

Follow this, the governor set by cpupower knows shit about CPU without this:

Permanent disable intel_pstate:
Edit: /etc/default/grub
and update grub:
grub-mkconfig -o /boot/grub/grub.cfg

And then enable acpi-cpufreq module:
su root
echo "acpi-cpufreq" > /etc/modules-load.d/acpi-cpufreq.conf


Now cpupower can set frequencies properly.

To disable throtling
sudo pacman -S cpupower
sudo cpupower frequency-set -g performance
It should apply to all cores, but if it only apply to the first one: copy files to the other (4 in laptop)
sudo cp /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

To restore:
sudo cpupower frequency-set -g ondemand
If not all cores are set:
sudo cp /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

This stuff is only required at build time.

paulkerry commented on 2017-06-07 09:37

In case it helps anyone, to build this package I had to disable hyperthreading in BIOS to stop the "throttling error" and then set the cpu governor to performance (cpupower frequency-set -g governor).

tindzk commented on 2017-01-12 13:45

I encountered the same compilation problem and could fix it by adding the patch from

ArchangeGabriel commented on 2016-09-06 21:09

@mamstriz: atlas-lapack-base didn’t complain at all, because it wasn’t optimized for your specific setup.

That’s said, I don’t know why it was removed from the repo, but you still have the option to install blas, cblas and/or lapack instead for python2-numpy and the likes. ;)

marmistrz commented on 2016-09-02 20:44

Ok, this seems to be the reason why I failed to compile it without intel-pstate. My CPU uses Intel Turbo Boost.

Is it possible to install this without such tricks? Many common packages need this, e.g. python2-numpy, r.

The old package atlas-lapack-base didn't complain at all.

nTia89 commented on 2016-08-19 15:59

today I give it another try, since I noticed about this bug (

at this time, I was successful by booting with `intel-pstate=disable` kernel parameter AND, together with, disabling the SpeedStep intel feature from the bios of my laptop

now, is there a way to check out the performance, in order to compare the performance increase of the compiled package versus the pre-compiled one?

EDIT: I was successful (compilation starts) even with the combination of: disabling intel_pstate, disabling ppc through kernel parameters and forcing the performance governor using cpupower tool

EDIT2: I added a little section in our archwiki ( in order to help fellows.
This is a very preliminary draft version, so every edit is welcome

EDIT3: how does the compilation should handle intel TurboBoost technology, since this is disabled when disabling pstate?

marmistrz commented on 2016-08-18 18:08

Have problems too, using TLP. Have the same lines in dmesg:

[ 0.033503] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.033503] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

bartus commented on 2016-08-11 11:59

A neat solution would be to add 'wait' function beside the prompt - and gave user a chance to change cpu-governor before starting the build procedure.

Similar solution can be found in Slic3r-git PKGBUILD which allow user to tune the branch before starting the build.

nTia89 commented on 2016-07-31 09:27

I've already tried it

PS: my CPU is an Intel Broadwell

EDIT: maybe related to these lines found with dmesg?
[ 0.027339] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.027339] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

giniu commented on 2016-07-31 09:24

Try also hints from - might help. There are too many ways to set this to do automatically - and it might require root permissions for some - so it cannot be part of PKGBUILD unfortunately.

nTia89 commented on 2016-07-31 08:55

given that, it's the first time I'm trying to compile this package,
I'm not able to compile it!
It always gives me the "throttling error"

I've tried every kind of suggestion, stated below but with no luck...

PS: I'm on a laptop, with `tlp` installed

giniu commented on 2016-07-30 16:49

I've made some changes to this package. Please test if possible. It needs further refreshment, but I don't have time for it now. Patches/PKGBUILDs with updates are welcome, I can also pass this to someone with more time at hand.

kgizdov commented on 2016-07-26 09:25

@peder2tm, yep, failed at the same step for me. It is definitely a bug.

melissawm commented on 2016-06-11 21:27

Hi all,

I'm trying to build this package via makepkg in order to include it in CCR (chakra does not provide this package) and I get the following error:

cp: impossível obter estado de '/home/melissa/atlas_lapack_package_chakra/atlas-lapack/src/ATLAS/build/lib/libsatlas.dylib': Arquivo ou diretório não encontrado recipe for target 'install_lib' failed
make[1]: [install_lib] Error 1 (ignored)

Checking the make files I got this from Make.lib:

# =======================================================================
# The following commands are to build dynamib libraries on OS X (in BETA)
# =======================================================================
dylib :
rm -rf $(tmpd) ; mkdir $(tmpd)
cd $(tmpd) ; ar x ../liblapack.a
cd $(tmpd) ; ar x ../libf77blas.a
cd $(tmpd) ; ar x ../libcblas.a
cd $(tmpd) ; ar x ../libatlas.a
cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libsatlas.dylib \
-install_name $(LIBINSTdir)/libsatlas.dylib -current_version $(VER) \
-compatibility_version $(VER) *.o $(LIBS) $(F77SYSLIB)
rm -rf $(tmpd)

So apparently this dylib file is meant for OSX. Why do we need this to be built on Linux? How do I avoid this if this is the case? I didn't touch the PKGBUILD file so this must happen in archlinux as well...

I'm new to package building to please forgive my noobness if this is totally wrong, but any help is appreciated.


peder2tm commented on 2016-05-23 12:08

I had to add -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/ to
to make it compile, i.e. the make targets become: : liblapack.a
ld $(LDFLAGS) -shared -soname -o $@ --whole-archive \
liblapack.a --no-whole-archive $(F77SYSLIB) -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/ -L. -lstcblas -lf77blas -lgcc_s : libptlapack.a
ld $(LDFLAGS) -shared -soname -o $@ --whole-archive \
libptlapack.a --no-whole-archive $(F77SYSLIB) -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/ -L. -lcblas -lblas -lgcc_s

peder2tm commented on 2016-05-21 09:50

I get the following error towards the end of compilation but gcc-libs is installed.

==> Build shared libraries
ld -melf_x86_64 -shared -soname -o --whole-archive libatlas.a \
--no-whole-archive -lc -lpthread -lm
ld -melf_x86_64 -shared -soname -o --whole-archive \
libf77blas.a --no-whole-archive -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib -lgfortran -L. -latlas
ld -melf_x86_64 -shared -soname -o --whole-archive \
libptf77blas.a --no-whole-archive -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib -lgfortran -L. -latlas
ln -s
ld -melf_x86_64 -shared -soname -o --whole-archive \
libcblas.a -L. -latlas -lblas
ld -melf_x86_64 -shared -soname -o --whole-archive \
libptcblas.a -L. -latlas -lblas
ln -s
ld -melf_x86_64 -shared -soname -o --whole-archive \
liblapack.a --no-whole-archive -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib -lgfortran -L. -lstcblas -lf77blas -lgcc_s
ld: cannot find -lgcc
makefile:34: recipe for target '' failed
make: *** [] Error 1
==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build atlas-lapack.

bartbkr commented on 2016-04-16 17:27

I was finally able to get this working. The reason that the build was failing was that the maximum CPU frequency was being limited by the BIOS. I had to tuhrn off the max CPU freq limit set by the BIOS and ensured that the maximum frequency was that allowed by cpupower, namely 2.401GHZ.


bartbkr commented on 2016-04-10 17:11

Right, I tried to make it clear from my initial post that I've already done what was instructed on that page and the linked SE answer. I am still getting the "CPU Throttling is enabled!" error.

Some output:

$ cat /sys/devices/systemt/cpu/cpu*/cpufreq/scaling_governor

$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us
hardware limits: 400 MHz - 2.40 GHz
available frequency steps: 2.40 GHz, 2.40 GHz, 2.30 GHz, 2.10 GHz, 2.00 GHz, 1.80 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.10 GHz, 1000 MHz, 800 MHz, 700 MHz, 500 MHz, 400 MHz
available cpufreq governors: ondemand performance
current policy: frequency should be within 400 MHz and 2.10 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: 2.10 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes

morealaz commented on 2016-04-09 16:34

for disabling CPU Throttling.

bartbkr commented on 2016-04-09 14:49

I have Intel Core i5 processor. I've confirmed that now using the acpi_cpufreq driver and intel_pstate=disable on boot. scaling_governor for all four cores is set to performance.

I am still getting the "CPU Throttling is enabled!" error and cannot build. Any suggestions?

greyltc commented on 2016-02-27 12:07

My cpu scaling driver is intel_pstate. By default I'm using the performance governor. Can anyone give me a tip on how to compile this package *without* having to reboot?

giniu commented on 2016-02-25 14:36

@arojas - yes, but provides+conflicts is good anyway in this case I think.

arojas commented on 2016-02-25 12:00

No package should depend on atlas-lapack-base. If some do, it's a bug and should be fixed. Packages should depend on atlas-lapack, atlas-lapack-base is provided as a generic implementation in the repos so that official packages (such as sagemath) can depend on atlas-lapack, but it should be clear that atlas-lapack is the 'right' package to use.

giniu commented on 2016-02-21 07:00

Hi - I will deal with providing atlas-lapack-base together with next upstream release (when this package was built, there was no atlas-lapack-base yet). It will come soon.

budgerigar commented on 2016-02-20 23:31

Maybe there should be a provide for atlas-lapack-base because some packages depend on it which is a official package, and atlas-lapack can replace it.

seanl commented on 2016-02-19 04:59

See for how to turn off cpu throttling if you are using intel_pstate. (TL;DR: boot with intel_pstate=disable, then modprobe acpi-cpufreq, then cpupower frequency-set -g performance).

I did this, and it's no longer aborting due to cpu throttling, but now I'm having a strange problem (64 bit):

cd bin/ ; ./xatlas_build -1 0 -a 1 -l 1
Can't recognize 'make IArchDef.grd
' as an internal or external command, or batch script.

Is it using the wrong shell or something?

ArchangeGabriel commented on 2015-12-29 11:34

Does not work for me.

Question: is anyone here using intel-pstate as governor? Or are you guys using cpufreq?

jose1711 commented on 2015-12-28 20:12

ok, i take it back. did cpupower frequency-set -g performance and it compiled fine

ArchangeGabriel commented on 2015-12-27 21:53

@jose1711: I have the same issue on my laptop, on my server, on a friend laptop… And nothing I’ve tried to disable throttling worked in regard to compiling ATLAS…

jose1711 commented on 2015-12-27 21:49

Parallel make command configured as '$(MAKE) -j 2'
CPU Throttling apparently enabled!
It appears you have cpu throttling enabled, which makes timings
unreliable and an ATLAS install nonsensical. Aborting.
See ATLAS/INSTALL.txt for further information
xconfig exited with 1

giniu commented on 2015-11-14 20:23

Thanks, I will check it out.

greyltc commented on 2015-11-14 10:19

Hi giniu, could you please have a look at the recent change in atlas-lapack-base:

which was made to fix:

and make the same change here? Thanks.

piratejon commented on 2015-10-22 00:09

I am getting a different MD5 for atlas3.10.2.tar.bz2 which is 0103b909e19ca9c6497a7ae696c16480

ArchangeGabriel commented on 2015-10-14 22:48

I’m having trouble w.r.t. disabling cpu throttling.

Build fails on:
CPU Throttling apparently enabled!
It appears you have cpu throttling enabled, which makes timings
unreliable and an ATLAS install nonsensical. Aborting.

I’ve set all the core to performance, force them to be at their maximum frequency, but it still fails.

epitron commented on 2015-09-10 03:15

Strange issue: when the `afl` package is installed, ATLAS tries to use `afl-gcc` instead of `gcc`.

I skimmed the configure script and the Makefile, and there doesn't seem to be anywhere it's searching for an alternative gcc executable. Passing congfigure the `--cc=gcc` option, or setting the CC environment variable to `CC=gcc` both have no effect.

The simplest solution is to remove the `afl` package when you're building ATLAS. Does anyone have a better solution?

Chais commented on 2015-05-04 18:23

This seems to be missing most of the headers. All the libs are there, but only cblas.h and clapack.h are in /usr/include.

giniu commented on 2015-04-29 12:58

Then maybe you have small amount of /tmp size on tmpfs? Most AUR helpers build in /tmp, so sometimes they get stuck when you run out of /tmp space.

mutor commented on 2015-04-29 12:54

Hey giniu,
this week I tried to install it using simple pkgbuild method, it has worked. earlier I was using AURA, that had failed couple of times.

giniu commented on 2015-04-24 09:14

it takes well too long. Can you somehow pass me the file that is mentioned in this log? I.e. error_<ARCH>.tgz - there are all informations about how configure went and what decisions were taken during build, so it would help a lot.

mutor commented on 2015-04-24 08:55

Build is failing for gcc 4.9.2, and is it supposed to take 7 hours? my CPU is AMD 8350 8-core. Log is following:

gcc version 4.9.2 20150304 (prerelease) (GCC)
/usr/bin/x86_64-unknown-linux-gnu-gcc-4.9.2 -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
x86_64-unknown-linux-gnu-gcc-4.9.2: error: unrecognized command line option ‘-V’
x86_64-unknown-linux-gnu-gcc-4.9.2: fatal error: no input files
compilation terminated. recipe for target 'error_report' failed
make[4]: [error_report] Error 1 (ignored)
/usr/bin/x86_64-unknown-linux-gnu-gcc-4.9.2 --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
tar cf error_AMDDRIVER64AVXMAC.tar bin/INSTALL_LOG/*
bzip2 error_AMDDRIVER64AVXMAC.tar
make[4]: Leaving directory '/var/cache/pacman/pkg/atlas-lapack2194/atlas-lapack/src/ATLAS/build'
make[3]: Leaving directory '/var/cache/pacman/pkg/atlas-lapack2194/atlas-lapack/src/ATLAS/build'
make[2]: Leaving directory '/var/cache/pacman/pkg/atlas-lapack2194/atlas-lapack/src/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 recipe for target 'build' failed
make[1]: *** [build] Error 255
make[1]: Leaving directory '/var/cache/pacman/pkg/atlas-lapack2194/atlas-lapack/src/ATLAS/build'
Makefile:488: recipe for target 'build' failed
make: *** [build] Error 2

arojas commented on 2013-11-11 07:57

The build failure should be fixed with glibc 2.18-10

kyak commented on 2013-10-04 20:18

@Marbur thanks, adding "-D c -DWALL" only in PKGBUILD made it work for me!

MarBur commented on 2013-10-04 19:57

On further checking downgrading gcc isn't necessary.
Try first with only -D c -DWALL without pstate change or anything it might work.
I used pstate because I needed atlas badly and didn't have time to figure out all combinations of working and non-working.

And changing kernel cmdline is 2 minute work and one restart.
Maybe if you can turn off power sawing this isn't necessary but my frequency kept changing no matter what I did.

kyak commented on 2013-10-03 16:28

Hm, not only i have to downgrade GCC, but also need to change my kernel cmdline. Unfortunately, the upstream doesn't seem to react. And there is too much of a hassle to make all these changes. Could someone upload a package for x64?

sfpotter commented on 2013-10-01 23:17

I was having the same issue with this package. Following the instructions in MarBur's latest comment, including setting intel_pstate=disable, I was able to build the package without issue.

MarBur commented on 2013-09-19 15:14

Atlas compiles with GCC 4.7 if I configure it with -D c -DWALL in addition to other settings in PKGBUILD. This uses wall timer for timing meaning that computer mustn't be busy.
I also booted with intel_pstate=disable because processor frequency didn't stay at 3.4 Ghz on performance governor if intel_pstate was configuring frequency.

kyak commented on 2013-09-17 17:22

@MarBur that's one great bug report. Let's see how upstream responds.

giniu commented on 2013-09-17 17:11

I don't think this is related to package itself, I will monitor this issue upstream. Thanks for reporting.

MarBur commented on 2013-09-17 13:48

I have the same error:

But I think the real error is higher up:
make[5]: *** [RunMADef] Aborted (core dumped)
make[5]: Leaving directory `/tmp1/yaourt-tmp-mabu/aur-atlas-lapack/src/ATLAS/build/tune/sysinfo'
xsyssum: /tmp1/yaourt-tmp-mabu/aur-atlas-lapack/src/ATLAS/build/..//tune/sysinfo/GetSysSum.c:92: getfpinfo: Assertion `system(ln) == 0' failed.

Full report:

kyak commented on 2013-09-13 18:32

gcc version 4.8.1 20130725 (prerelease) (GCC)
/usr/bin/gcc -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
make[4]: [error_report] Error 1 (ignored)
/usr/bin/gcc --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
tar cf error_Corei264AVX.tar bin/INSTALL_LOG/*
bzip2 error_Corei264AVX.tar
make[4]: Leaving directory `/home/user/build/atlas-lapack/src/ATLAS/build'
make[3]: Leaving directory `/home/user/build/atlas-lapack/src/ATLAS/build'
make[2]: Leaving directory `/home/user/build/atlas-lapack/src/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/user/build/atlas-lapack/src/ATLAS/build'
make: *** [build] Error 2
==> ERROR: A failure occurred in build().
:: atlas-lapack cleaned

giniu commented on 2013-03-01 20:34

I adopted this package. For now I just updated it and walked around archive bug. I will clean it up during following updates.

gborzi commented on 2013-01-28 15:10

I'm going to orphan this package. I'm using openblas now, and this package is a pain to maintain.

giniu commented on 2013-01-27 11:43

When you update ATLAS to new release (atlas 3.10.1) look out for bsdtar issue:

for some reason it fails to extract the archive, you can walk around this, add sources to noextract and extract them by hand using "tar"

PedsXing commented on 2013-01-27 09:53

Running ATLAS' performance check with make time I seem to get a rather bad performance compared to the reference performance obtained by the ATLAS authors.
Is there any explanation for that? Does anyone get better results?

giniu commented on 2012-11-29 21:21

Are you sure you don't want to bump it? The package without this space is somewhat 11mb smaller if I remember correctly results I got.

gborzi commented on 2012-11-29 21:04

thanks, I've fixed the PKGBUILD, but without changing the release number.

giniu commented on 2012-11-29 18:07

I believe there is a mistake in PKGBUILD, i.e. missing space before ] in line 79.

bred commented on 2012-09-25 16:16

I've always this error:

==> Build ATLAS
gcc -I/home/simone/packages/atlas-lapack/src/ATLAS/build/..//CONFIG/include -g -w -c /home/simone/packages/atlas-lapack/src/ATLAS/build/..//CONFIG/src/atlconf_misc.c
gcc -I/home/simone/packages/atlas-lapack/src/ATLAS/build/..//CONFIG/include -g -w -o xconfig /home/simone/packages/atlas-lapack/src/ATLAS/build/..//CONFIG/src/config.c atlconf_misc.o
./xconfig -d s /home/simone/packages/atlas-lapack/src/ATLAS/build/../ -d b /home/simone/packages/atlas-lapack/src/ATLAS/build -b 64 -Fa alg -fPIC -Si lapackref 1

OS configured as Linux (1)

Assembly configured as GAS_x8664 (2)

Vector ISA Extension configured as AVX (5,480)

Architecture configured as Corei2 (26)

Clock rate configured as 1600Mhz

Maximum number of threads configured as 8
Parallel make command configured as '$(MAKE) -j 8'
CPU Throttling apparently enabled!
It appears you have cpu throttling enabled, which makes timings
unreliable and an ATLAS install nonsensical. Aborting.
See ATLAS/INSTALL.txt for further information
xconfig exited with 1

Anonymous comment on 2012-08-29 12:57

Is it possible to add a link -> ?
Unfortunately this is done by Debian, so some packages look for it
in order to find ATLAS.

gborzi commented on 2012-08-04 23:02

Hi giniu,
I can't do it right now, I hope I'll upload a new version on monday. Thanks for reporting the problem and the fix.

giniu commented on 2012-08-04 21:34

Hi, there is serious regression for machines without SSE2, like Pentium III. I reported it upstream ( see ) and solution was found: - would be great to include that patch before new release, because it makes ATLAS badly fail on SSE1-only hardware during build, rendering it unusable.

gborzi commented on 2012-07-13 16:12

Updated to 3.10.0. Please let me know of any problem with this package. Now I use it only on one of the computers I manage, so I'm not able to extensively test it.

Anonymous comment on 2012-07-12 20:30

New stable ATLAS 3.10.0 has been released

gborzi commented on 2012-07-01 14:33

This new version addresses the problems pointed to by jedbrown.

gborzi commented on 2012-06-27 07:59

No, because cpufrequtils is useful only on those systems that support it, i.e. laptops, but it is useless, hence not installed, on workstations. The latter computers are a more suitable candidate for this package than the former ones.

Liquen commented on 2012-06-26 17:22

Shouldn't cpufrequtils be in makedepends?

jedbrown commented on 2012-06-15 18:31

Hmm, with static libraries, the established API is certainly that the application links the preferred libblas.a. But with shared libraries, we have to decide up-front because of -Wl,--as-needed. I think that if it was up to me, I'd link a and a, but I can understand not wanting to do that, so use your judgement.

gborzi commented on 2012-06-15 18:22

Thanks for your advice, but I have a doubt about Should it point to or Some of the packages in the repos that use blas and/or lapack don't use threading (AFAIK octave, arpack, suitesparse don't). Moreover, should be linked against the MT or ST lib{c,f77}blas? Or none?

jedbrown commented on 2012-06-14 21:49

@gborzi FWIW, I think this is a bad default. Many parallel programs do the threading (or processes) at a higher level and *do not* want a threaded BLAS by default. Secretly using extra threads is a good way to create very confusing performance and cause great annoyance when reconfiguring (especially since Atlas take so long to build).

gborzi commented on 2012-06-14 21:43

for multi-threaded machines the and are built with libptcblas.a and libptf77blas.a respectively, so they're actually and Look at for details. For single-threaded machines pt libraries are not built.
If you need both kinds of libraries, you have to change accordingly.

Anonymous comment on 2012-06-14 20:04

The package worked beautifully, but it is not installing ptcblas or ptf77blas. The ".a" files were built though. Is there any flag or dependency missing to generate and install it?...

Anonymous comment on 2012-06-14 19:30

Wroked after a system upgrade...

gborzi commented on 2012-06-14 19:17

you have a problem with your makepkg, the error messages are from it, not from the compiled binary. You miss /usr/bin/du in your box. It is part of coreutils, perhaps it got corrupted.

Anonymous comment on 2012-06-14 18:33

I could not build it today. Here are the last few messages from makepkg -s.

cp /home/nlw/aursrc/atlas-lapack/src/ATLAS/build/lib/libf77blas.a /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/.
chmod 0644 /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/libf77blas.a
cp /home/nlw/aursrc/atlas-lapack/src/ATLAS/build/lib/libptcblas.a /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/.
cp /home/nlw/aursrc/atlas-lapack/src/ATLAS/build/lib/libptf77blas.a /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/.
chmod 0644 /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/libptcblas.a /home/nlw/aursrc/atlas-lapack/pkg/usr/lib/libptf77blas.a
make[1]: Leaving directory `/home/nlw/aursrc/atlas-lapack/src/ATLAS/build'
==> Tidying install...
-> Purging unwanted files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
==> WARNING: Package contains reference to $srcdir
==> Creating package...
/usr/bin/makepkg: line 1129: /usr/bin/du: No such file or directory
/usr/bin/makepkg: line 1130: * 1024 : syntax error: operand expected (error token is "* 1024 ")
==> Finished making: atlas-lapack 3.8.4-3 (Thu Jun 14 14:37:52 BRT 2012)
==> Finished making: atlas-lapack 3.8.4-3 (Thu Jun 14 14:37:53 BRT 2012)

gborzi commented on 2012-06-13 11:24

Why has this package been flagged out of date? The stable atlas release is still at 3.8.4, cpupower is still in community, while cpufrequtils is in extra. In case it doesn't compile please post the error message.

Huulivoide commented on 2012-05-24 21:44

cpufreq-* has been replaced/deprecated by cpupower utility

gborzi commented on 2012-04-29 13:10

I've just uploaded a new PKGBUILD that fix the problem with a line that unsets MAKE before building atlas. I've not changed the pkgver, recompiling this package is a pain.

gborzi commented on 2012-04-29 12:56

I've just uploaded a new PKGBUILD that fix the problem with a line that unsets MAKE before building atlas. I've not changed the pkgver, recompiling this package is a pain.

Anonymous comment on 2012-04-29 02:51

makepkg fails with the following message:

make[2]: Leaving directory `/home/oscar/atlas-lapack/src/ATLAS/build/bin'

$echo $MAKE
make -j6

When I changed to
$ export MAKE=make

compilation was successful.

gborzi commented on 2011-12-21 06:21

The previous (-2) version had an almost empty lapack library, due to a stupid mistake I did in the PKGBUILD. This version should fix it. Sorry for the inconvenience of rebuilding this package.

gborzi commented on 2011-12-10 15:21

Sorry for forgetting the patch. The package has been updated again.

gdiscry commented on 2011-12-10 14:15

And finally, you should use "egrep '^processor' /cpu/cpuinfo" when detecting the number of CPU, I have an old Pentium M and the model name contains the string "processor" too, so the PKGBUILD thinks I have 2 processors.

gborzi commented on 2011-12-10 14:13

I did the requested changes. The problem with the lapack md5 is due to the fact that at netlib they keep changing the tarball without changing the version number. It is already the second time that it happens.

gdiscry commented on 2011-12-10 14:11

You also forgot to apply the patch here's patch for the PKGBUILD

--- atlas-lapack.orig/PKGBUILD 2011-12-10 13:30:42.000000000 +0100
+++ atlas-lapack/PKGBUILD 2011-12-10 15:06:36.050601953 +0100
@@ -15,7 +15,7 @@
provides=("blas" "lapack=$_lapackver" 'cblas')
license=('custom:blas' 'custom:lapack' 'custom:atlas')
source=($_lapackver.tgz${pkgver}.tar.bz2 blas-license.txt atlas-license.txt lapack.patch misdetects_i1_as_i2.patch)
@@ -64,7 +64,9 @@

msg 'Build ATLAS'
- cd "$srcdir/ATLAS/build"
+ cd "$srcdir/ATLAS"
+ patch -uNp0 -i "$srcdir/misdetects_i1_as_i2.patch"
+ cd "build"
rm -rf *
../configure --prefix=/usr/ $ARCHITECTURE_BUILD_OPTS -Fa alg -fPIC \

gdiscry commented on 2011-12-10 13:56

The MD5 for the LAPACK sources fails.

Also, could you create the build directory with mkdir -p so that it doesn't fail if we stop and restart makepkg ?

gborzi commented on 2011-12-10 12:45

Updated with lapack 3.4.0 and the patch suggested by Murmex. Thanks Murmex.

gdiscry commented on 2011-12-10 11:39

Problem solved for the compilation on Intel Core i1 processors, this was actually in the errata:

Add the following patch:
--- ATLAS/CONFIG/src/backend/archinfo_x86.c.orig 2011-12-10 12:03:57.816977701 +0100
+++ ATLAS/CONFIG/src/backend/archinfo_x86.c 2011-12-10 12:04:04.347061389 +0100
@@ -309,9 +309,9 @@
case 0x1A:
case 0x1E:
case 0x1F:
+ case 0x25:
iret = IntCorei1;
- case 0x25:
case 0x2A:
iret = IntCorei2;

gdiscry commented on 2011-12-10 09:53

I'm not sure, but looks like Netlib LAPACK 3.4.0 has been released.

I have a problem similar to deb's on a Core i5. I found the following bug:

3.8.4 is the latest stable release so I'll try with an unstable release and see if it works. Anyway, providing more information in that bug report might be useful.

gborzi commented on 2011-12-03 11:24

Why was this package flagged out of date?

Anonymous comment on 2011-10-25 07:47


I tried to compile this package on a Core i3-380UM, it failed because of the program "xL1" who was denied some illegal instructions (wonder what it is)
maybe this has something to do with compilation options ? I commented out USE_ARCH_DEFAULTS, no effects. I googled this kind of error but did not found any solutions,
any hints ?

Thanks for this package

gborzi commented on 2011-10-21 18:21

Hi orbisvicis,
thanks for the updated PKGBUILD. I'll update a new package, based on your PKGBUILD, but without changing the pkgver number. Compiling it anew is a real pain. Note that the lapack patch is used to remove some object files from the library that contain subroutines already available in atlas. I agree that the performance isn't something to write home about. Try gotoblas2 instead. It's much faster than ATLAS on Intel processors and compiles in a much shorter time. On AMD processor gotoblas2 has about the same performance as ATLAS, but still it's easier to compile.

orbisvicis commented on 2011-10-21 17:54

This package is quite a pain to build!
I made a few very slight changes to the PKGBUILD @
For example, modern bashisms (which is OK, since makepkg depends explicitly on bash), combined {echo,sed,grep} to sed only, fixed one regex, made the patch name clearer.

I think USE_ARCH_DEFAULTS no longer has any effect. It made no difference (performance/time) compiling with or without it, and the docs or the ATLAS source make no mention of it. The installation guide says to use "-Si archdef 0" to ignore architectural defaults.

Also, it seems the lapack patch is no longer needed. Builds fine without it... so I commented it out.

However, I'm not too happy with the performance (CoreDuo32SSE3)

In case anyone is looking for a standard benchmark, HPL (A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers) works very well.

I built HPL against netlib-fortran-blas, atlas-fortran-blas, atlas-cblas-nothreads, atlas-cblas-threads and used to generate the HPL.dat file, geared towards a single dual-core machine

relevant: settings reproduced here
2 # of problems sizes (N)
1000 2000 Ns
1 # of NBs
128 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
1 Ps
1 Qs

These are my results:
. 0.97
. 7.93
. 0.61
. 4.72
. 0.41
. 3.02
. 0.40
. 2.84

The values are pretty consistent across various runs.

awim commented on 2011-07-23 21:36


gborzi commented on 2011-07-23 21:15

I think you need to include clapack.h and link to liblapack, but I haven't tried it. I've used this package to use lapack from within C/C++ code.

awim commented on 2011-07-23 21:03

using this package would i be able to call LAPACK routines from my C++ code without having to convert the matrices to column-major mode before making the call and then changing back to row-major mode after the call?

Anonymous comment on 2011-06-01 03:39

ATLAS 3.8.4 is out :)

gborzi commented on 2011-03-20 17:07

Hi Dieter_be,
with USE_ARCH_DEFAULTS enabled my compilation of ATLAS failed, so it is disabled by default. As for multithreading/multiprocessing it works on my systems, i.e. I can see on system monitor that all cores are involved in the computation.
Sorry for the delay in answering your comments.

Dieter_be commented on 2011-03-08 16:30

Another thing, why don't you leave USE_ARCH_DEFAULTS enabled by default? strongly encourages it.

Dieter_be commented on 2011-03-08 11:29

ATLAS 3.8.0's architectural defaults are for gcc 4.2, and you are presently using 5.1, it might be possible that things have changed enough to require new defaults, and if you are using a bad compiler like gcc 4.1 or an old one like gcc 3, you will almost certainly not want to use the architectural defaults.

arch has 4.5, which is probably different enough from 4.1
(I'm not seeing any performance improvement when using atlas-lapack together with scipy, and i'm trying to find out why)

Dieter_be commented on 2011-03-04 16:32

Btw, does anyone know if this package supports multithreading/multiprocessing?
I'm running python-gensim calculations with it and i see constantly 1 core 100%, the others unloaded. Or maybe my vectors/matrices are too small to be distributed or something.

gborzi commented on 2011-03-04 14:36

Hi Dieter_be,
it would be a nice thing, but I don't know how to do it. You have to ask to upstream.

Dieter_be commented on 2011-03-04 13:04

Yeah I finally managed to build it, by not touching my pc for a whole night ;)
But still it would be convenient if the build system would "remember" discovered system parameters so it doesn't need to do the entire thing again whenever something fails.

gborzi commented on 2011-02-28 17:03

Hi Dieter_be,
I've googled that error message, and it appears when the system is under heavy load while compiling ATLAS. Please retry with your system as idle as possible.

Dieter_be commented on 2011-02-28 16:02

btw I get "VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS." every single time and it gets on my nerves :/

Dieter_be commented on 2011-02-28 11:27

is there a way to make the "system specifications discovery" cache things?
I'm having issues getting this thing built on my i3 quadcore (see ), and redoing those parts takes a looong time (I need to shutdown my system after 8 hours or so)
Also, I notice the configure script has quite some options, but I'm not sure whether I should use them at all.

gborzi commented on 2011-02-08 20:49

Updated with lapack 3.3.0.

fhs commented on 2011-02-04 21:30

I got it to build successfully after couple of attempts:

1. I built with USE_ARCH_DEFAULTS="yes". It went to the next test and failed, similar to the previous failure.
2. I built without USE_ARCH_DEFAULTS="yes", but this time in an idle system, seeing how my system was relatively idle the first time I tried to compile atlas and it passed all the tests. This was a successful build.

I don't know how much it matters that your system is idle when you're building atlas. Maybe it doesn't matter and it's something totally random.

Anyway, thanks for all the help.

gborzi commented on 2011-02-03 19:58

Hi fhs,
from the previous error it looked like the static libraries were successfully compiled, and then the shared libraries building failed. Now, the latest error seems to happen during the testing phase, which is before the shared libraries building. Searching the net for the error message you've reported, I have found a possible solution on Slackware ml: add a line with USE_ARCH_DEFAULTS="yes" before the building process, for example after the NCPU line in build().

fhs commented on 2011-02-03 01:01

Now I'm getting this error:

/tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build/bin/ /tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build/bin xzslvtst -n 167 -r 83 -O 2 c r \
>> /tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build/bin/sanity.out
RHS=1, nrm=312725833108.707520
RHS=18, nrm=13179634283979495453549247608549742468923990200446644223307526161094608900911702216544160326059569078537280460836082931375877196186976619041294138293392679425688758274068510126468611500498776309379399760253210086632000009749486685492468139411362441467328194429181105576869888.000000
RHS=31, nrm=298971255263.120972
RHS=1, nrm=222314426647.809845
RHS=31, nrm=175980884682.206482
RHS=36, nrm=1164628890293.682861
make[3]: *** [zsanity_test] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build/bin'
make[2]: *** [sanity_test] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build/bin'
make[1]: *** [sanity_test] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-fhs/aur-atlas-lapack/src/ATLAS/build'
make: *** [test] Error 2

Let me know if you need more info.

gborzi commented on 2011-02-02 19:51

Hi fhs,
sorry for the error, but I have not a single core cpu to test the package. Thanks to eca forum member I've updated the package. Please try it and report any problem.

fhs commented on 2011-02-02 19:38

I'm getting the following error in an i686 single CPU system:

==> Build shared libraries
ld -melf_i386 -shared -soname -o --whole-archive libatlas.a \
--no-whole-archive -lc -lm
make: *** No rule to make target `libptf77blas.a', needed by `'. Stop.
==> ERROR: Makepkg was unable to build atlas-lapack.

gborzi commented on 2010-12-18 00:13

Those interested in this package please look here

mickele commented on 2010-11-21 18:13

Try this new version (3.8.3-9), I hope this will solve your issues.

mauro2 commented on 2010-11-18 00:41

After updating this package, the package python-numpy does not work anymore (in python2)
Importing it give the following error:
ImportError: /usr/lib/python2.7/site-packages/numpy/linalg/ undefined symbol: zgesdd_

This bug might have some bearings:

I tried to rebuild python-numpy but I failed.

mickele commented on 2010-10-24 19:59

Can you test this new version of atlas-lapack (3.8.3-8)?

mickele commented on 2010-10-19 07:05

I am working on a new PKGBUILD that should solve your problem.
It builds twice the library: the first time without option "-fPIC" for static library, and the second time with "-fPIC" to build shared ones.
Now I am testing the package, I think I'll upload this new version in a few days.

Anonymous comment on 2010-10-07 00:01

Problem semi-solved! There was a old stray .a w/o accompanying .so files in /usr/local/lib, while the good newly built files were installed in /usr/lib. CMake picked up on the stray. This was easy to fix, and compilation now goes past that point... only to find a similar situation with another library. Bottom line: okay, atlas-lapack is innocent of any wrongdoing.

Anonymous comment on 2010-10-06 20:16

Problem semi-solved! There was a old stray .a w/o accompanying .so files in /usr/local/lib, while the good newly built files were installed in /usr/lib. CMake picked up on the stray. This was easy to fix, and compilation now goes past that point... only to find a similar situation with another library. Bottom line: okay, atlas-lapack is innocent of any wrongdoing.

Anonymous comment on 2010-10-06 15:19

Wish I could, but the build system, which is itself massively complex in this project, insists on static. I will find some way to fool it...

jedbrown commented on 2010-10-06 10:22

You should not be trying to link a static archive into a shared library, use the shared or link the whole thing statically.

Anonymous comment on 2010-10-06 08:44

Looks like -fPIC is needed somewhere in PKGBUILD. In bulding a large app depending on atlas/lapack/blas, I couldn't create an .so due to it wanting to link liblapack.a, but apparently the .a files made by this package aren't made with -fPIC.

Anonymous comment on 2010-08-03 08:33

Required also by scalapack

mickele commented on 2010-04-19 21:27

I agree with giniu.
If you need the latest unstable atlasyou should create package atlas-lapack-dev, atlas-lapack refers only to the latest stable version.

giniu commented on 2010-04-19 20:59

I think 3.9 is unstable branch, isn't it? Atlas braks too often by itself and many apps are not 3.9 ready, so maybe atlas-lapack-dev would be better? I'd say stick with 3.8 for this :)

luismiguelgcg commented on 2010-04-19 20:45

Latest upstream version is 3.9.23.