Package Details: atlas-lapack 3.10.3-1

Git Clone URL: https://aur.archlinux.org/atlas-lapack.git (read-only)
Package Base: atlas-lapack
Description: Complete LAPACK and BLAS implementation using optimised ATLAS routines
Upstream URL: http://math-atlas.sourceforge.net/
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: 82
Popularity: 1.425293
First Submitted: 2008-04-24 01:36
Last Updated: 2016-07-30 16:48

Required by (170)

Sources (6)

Latest Comments

nTia89 commented on 2016-08-19 15:59

today I give it another try, since I noticed about this bug (https://bugs.archlinux.org/task/50202)

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 (https://wiki.archlinux.org/index.php/CPU_frequency_scaling#atlas-lapack_compilation) 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 http://math-atlas.sourceforge.net/atlas_install/node5.html - 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
Make.top:658: 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.

Thanks!

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 makefile.shared.mt
to make it compile, i.e. the make targets become:

liblapack.so.3.4.1 : liblapack.a libstcblas.so libf77blas.so
ld $(LDFLAGS) -shared -soname libstlapack.so.3 -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.so.3.4.1 : libptlapack.a libcblas.so libblas.so
ld $(LDFLAGS) -shared -soname liblapack.so.3 -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

All comments