Opened 7 years ago

Closed 6 years ago

#17075 closed enhancement (fixed)

Install blas pkgconfig files

Reported by: vbraun Owned by:
Priority: major Milestone: sage-6.4
Component: build Keywords:
Cc: fbissey, jpflori Merged in:
Authors: Jean-Pierre Flori, François Bissey Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: 432eb25 (Commits, GitHub, GitLab) Commit: 432eb258c5f1dc62a7eb50d54df82979894242cb
Dependencies: Stopgaps:

Status badges

Description (last modified by vbraun)

Install blas.pc file when building atlas

Change History (32)

comment:1 Changed 7 years ago by vbraun

This is not yet finished, but if you have any design input then now would be the time ;-)

comment:2 Changed 7 years ago by fbissey

Are we doing stages? First install a pc file for atlas (and OS X make it point to accelerate) and convert to that? Then work out how we replace ATLAS. Or do you plan to switch hard to something like openblas straight away?

My current patch for module_list.py and misc/cython.py live here ​https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/files/sage-6.4-blas.patch I considered that we basically needed two things:

  • the library to be linked (c)blas_lib
  • the folder containing the libraries (c)blas_dir

I probably need to harmonise between the two files.

We could also want a cblas_inc for headers but that is probably not necessary.

comment:3 Changed 7 years ago by vbraun

I don't want to do too much at once. For now ATLAS should stay the default. Though this ticket should work with at least one other BLAS implementation ;-)

There is no guarantee that all cblas libraries are in the same directory. What do you need cblas_dir for that can't be done with pkgconfig --libs?

comment:4 Changed 7 years ago by fbissey

In module_list.py, at least, we need to separate the two. We get code of the form 

     Extension('sage.gsl.dwt',
              sources = ['sage/gsl/dwt.pyx'],
              library_dirs = blas_dir,
              libraries=['gsl'] + blas_libs,
              define_macros=[('GSL_DISABLE_DEPRECATED','1')]),

As far as I can tell shoving everything into "libraries=" won't work. But pkg-config will helpfully give us all the directories that we need. So at least to build sage or any extensions you won't be able to just use pkgconfig --libs because distutils wouldn't grok it properly.

comment:5 follow-up: Changed 7 years ago by jpflori

My only comment so far is that we should take care of the strange variable LINBOX_BLAS set up by linbox/fflas-ffpack, written in share/cblas_config, and used in modules_list.py IIRC.

comment:6 in reply to: ↑ 5 Changed 7 years ago by fbissey

Replying to jpflori:

My only comment so far is that we should take care of the strange variable LINBOX_BLAS set up by linbox/fflas-ffpack, written in share/cblas_config, and used in modules_list.py IIRC.

*yes* so the file is created by the fflas-ffpack spkg for consumption in linbox. fflas-ffpack provides a fflas-ffpack-config which you would think would help... 

(sage-sh) fbissey@QCD-nzi3:sage-6.3.beta7$ fflas-ffpack-config --blas-libs  
-L/home/work/fbissey/sandbox/sage-6.3.beta7/local/lib -lcblas -latlas -L/home/work/fbissey/sandbox/sage-6.3.beta7/local/lib -llapack

And the problem with that output is lapack. My foggy memory tells me that configuring linbox with lapack leads to troubles in sage-on-gentoo (needs re-checking). If we move to .pc we can forget about the whole LINBOX_BLAS business. In sage-on-gentoo I patched fflas-ffpack to use pkg-config directly to find blas/cblas (but I commented lapack out) ​https://github.com/cschwan/sage-on-gentoo/blob/master/sci-libs/fflas-ffpack/files/fflas-ffpack-1.6.0-blaslapack-3.patch Strangely enough I don't need to do anything in linbox to pick up the right blas and I think the whole cblas-config is not useful in linbox because configure will call fflas-ffpack-config to get its values for BLAS_LIBS and BLAS_CFLAGS. I also cannot find a trace of cblas_config in module_list.py - that would have got my attention in sage-on-gentoo.

comment:7 follow-up: Changed 7 years ago by jpflori

As far as I'm aware:

  • the code in ffla-ffpack and linbox spkg-install scripts is duplicated, but only fflas writes it down to the cbals-config file.
  • linbox currently does not link to lapack!!! (I must have opended a ticket for that ages ago)

comment:8 in reply to: ↑ 7 Changed 7 years ago by fbissey

Replying to jpflori:

As far as I'm aware:

  • the code in ffla-ffpack and linbox spkg-install scripts is duplicated, but only fflas writes it down to the cbals-config file.
  • linbox currently does not link to lapack!!! (I must have opended a ticket for that ages ago)

liblinbox doesn't but liblinboxsage does! 

(sage-sh) fbissey@QCD-nzi3:sage-6.3.beta7$ ldd -r local/lib/liblinboxsage.so
        linux-vdso.so.1 (0x00007ffffbfde000)
        libntl.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libntl.so.3 (0x00007f15ebac4000)
        libgf2x.so.1 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgf2x.so.1 (0x00007f15eb8ad000)
        liblapack.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/liblapack.so.3 (0x00007f15eb077000)
        libf77blas.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libf77blas.so.3 (0x00007f15eae57000)
        liblinbox.so.0 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/liblinbox.so.0 (0x00007f15eac4f000)
        libgivaro.so.0 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgivaro.so.0 (0x00007f15ea9f2000)
        libgmpxx.so.4 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgmpxx.so.4 (0x00007f15ea7ec000)
        libgmp.so.11 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgmp.so.11 (0x00007f15ea57a000)
        libcblas.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libcblas.so.3 (0x00007f15ea357000)
        libatlas.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libatlas.so.3 (0x00007f15e9a7a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f15e981d000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f15e9514000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f15e9213000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f15e8e6b000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f15e8c54000)
        libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgfortran.so.3 (0x00007f15e8939000)
        libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libquadmath.so.0 (0x00007f15e86fc000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f15ec2c2000)
undefined symbol: maxMagnMP     (local/lib/liblinboxsage.so)
undefined symbol: findRNS       (local/lib/liblinboxsage.so)
undefined symbol: RNSbound      (local/lib/liblinboxsage.so)
undefined symbol: certSolveMP   (local/lib/liblinboxsage.so)
undefined symbol: certSolveRedMP        (local/lib/liblinboxsage.so)
undefined symbol: nonsingSolvLlhsMM     (local/lib/liblinboxsage.so)
undefined symbol: nonsingSolvRNSMM      (local/lib/liblinboxsage.so)
(sage-sh) fbissey@QCD-nzi3:sage-6.3.beta7$ ldd -r local/lib/liblinbox.so
        linux-vdso.so.1 (0x00007fffe41ff000)
        libgivaro.so.0 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgivaro.so.0 (0x00007f02187f2000)
        libgmpxx.so.4 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgmpxx.so.4 (0x00007f02185eb000)
        libgmp.so.11 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libgmp.so.11 (0x00007f021837a000)
        libcblas.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libcblas.so.3 (0x00007f0218157000)
        libatlas.so.3 => /home/work/fbissey/sandbox/sage-6.3.beta7/local/lib/libatlas.so.3 (0x00007f0217879000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f021761d000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f0217314000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0217012000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0216c6b000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f0216a54000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0218c57000)

Note that we don't link anything in the sage library to lapack - it is not in module_list.py. So anything using lapack in linboxsage is well contained.

comment:9 Changed 7 years ago by fbissey

cblas_config is read by the linbox spkg 

###############################################################################
# Set up environment variables:
###############################################################################
LD_CBLAS=`cat $SAGE_LOCAL/share/cblas_config`
LDFLAGS="$LDFLAGS -L$SAGE_LOCAL/lib $LD_CBLAS"

When fflas-ffpack got split from linbox, fflas-ffpack inherited the variable LINBOX_BLAS, it is not present anymore in the linbox spkg.

comment:10 Changed 7 years ago by fbissey

And I have just done a build of 6.4.beta4 with a linbox in which I removed the above two lines. 

(sage-sh) fbissey@QCD-nzi3:sage-6.4.beta4$ ldd -r local/lib/liblinbox.so
        linux-vdso.so.1 (0x00007fff8a9ff000)
        libgivaro.so.0 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgivaro.so.0 (0x00007f08b0731000)
        libgmpxx.so.4 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgmpxx.so.4 (0x00007f08b052a000)
        libgmp.so.11 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgmp.so.11 (0x00007f08b02b9000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f08aff72000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f08afc70000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f08af8c9000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f08af6b2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f08b0b96000)
(sage-sh) fbissey@QCD-nzi3:sage-6.4.beta4$ ldd -r local/lib/liblinboxsage.so
        linux-vdso.so.1 (0x00007fffdd33b000)
        libntl.so.3 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libntl.so.3 (0x00007f3281172000)
        libgf2x.so.1 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgf2x.so.1 (0x00007f3280f5b000)
        liblapack.so.3 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/liblapack.so.3 (0x00007f3280725000)
        libcblas.so.3 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libcblas.so.3 (0x00007f3280502000)
        libf77blas.so.3 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libf77blas.so.3 (0x00007f32802e1000)
        libatlas.so.3 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libatlas.so.3 (0x00007f327fa04000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f327f7a8000)
        liblinbox.so.0 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/liblinbox.so.0 (0x00007f327f5a0000)
        libgivaro.so.0 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgivaro.so.0 (0x00007f327f343000)
        libgmpxx.so.4 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgmpxx.so.4 (0x00007f327f13d000)
        libgmp.so.11 => /home/work/fbissey/sandbox/sage-6.4.beta4/local/lib/libgmp.so.11 (0x00007f327eecb000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f327ebc2000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f327e8c1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f327e519000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f327e302000)
        libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgfortran.so.3 (0x00007f327dfe7000)
        libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libquadmath.so.0 (0x00007f327ddaa000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3281970000)

I will check on a OS X machine but I think the whole cblas_config can be safely removed.

comment:11 Changed 7 years ago by fbissey

Interesting on OS X I get 

(sage-sh) fbissey@Mirage:sage-6.2.beta5$ otool -L local/lib/liblinboxsage.dylib 
local/lib/liblinboxsage.dylib:
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinboxsage.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libntl.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgf2x.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinbox.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgivaro.0.dylib (compatibility version 6.0.0, current version 6.1.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmpxx.4.dylib (compatibility version 5.0.0, current version 5.21.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmp.11.dylib (compatibility version 12.0.0, current version 12.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
(sage-sh) fbissey@Mirage:sage-6.2.beta5$ otool -L local/lib/liblinbox.dylib 
local/lib/liblinbox.dylib:
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinbox.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgivaro.0.dylib (compatibility version 6.0.0, current version 6.1.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmpxx.4.dylib (compatibility version 5.0.0, current version 5.21.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmp.11.dylib (compatibility version 12.0.0, current version 12.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

with or without these lines and we have 

(sage-sh) fbissey@Mirage:sage-6.2.beta5$ fflas-ffpack-config --blas-libs
/usr/lib/libcblas.dylib
(sage-sh) fbissey@Mirage:sage-6.2.beta5$ fflas-ffpack-config --blas-home

(sage-sh) fbissey@Mirage:sage-6.2.beta5$ fflas-ffpack-config --blas-cflags
-I/Users/fbissey/build/sage-6.2.beta5/local/include -D__FFLASFFPACK_HAVE_CBLAS

At this stage there may be something to do to fflas-ffpack.

comment:12 Changed 7 years ago by fbissey

Yes if I replace 

LINBOX_BLAS=/usr/lib/libcblas.dylib

by 

LINBOX_BLAS=-lcblas

I get 

(sage-sh) fbissey@Mirage:sage-6.2.beta5$ otool -L local/lib/liblinbox.dylib 
local/lib/liblinbox.dylib:
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinbox.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgivaro.0.dylib (compatibility version 6.0.0, current version 6.1.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmpxx.4.dylib (compatibility version 5.0.0, current version 5.21.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmp.11.dylib (compatibility version 12.0.0, current version 12.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
(sage-sh) fbissey@Mirage:sage-6.2.beta5$ otool -L local/lib/liblinboxsage.dylib 
local/lib/liblinboxsage.dylib:
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinboxsage.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libntl.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgf2x.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/liblinbox.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgivaro.0.dylib (compatibility version 6.0.0, current version 6.1.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmpxx.4.dylib (compatibility version 5.0.0, current version 5.21.0)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgmp.11.dylib (compatibility version 12.0.0, current version 12.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/fbissey/build/sage-6.2.beta5/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
(sage-sh) fbissey@Mirage:sage-6.2.beta5$

so we end up with blas in both liblinbox and liblinboxsage. Most curious.

comment:13 Changed 7 years ago by fbissey

I see I had restored linbox to its original state. If I remove the two lines reading cblas_config. blas disapear from liblinbox.dylib. I guess if there was --as-needed option for OS X we could check that it is indeed not needed for liblinbox. I checked the Makefile.am for liblinbox and liblinboxsage and it is clearly the intent that only the sage interface depends on blas.

So for linbox I think we should make a small change in fflas-ffpack for OS X, remove the cblas_config file and update the linbox spkg accordingly.

comment:14 Changed 7 years ago by fbissey

Preliminary clean up of fflas-ffpack+linbox is now #17087.

comment:15 Changed 7 years ago by jpflori

For info, an old ticket I opened is at #14390.

comment:16 Changed 7 years ago by fbissey

Was looking at integrating coinor-cbc in sage-on-gentoo and then I noticed that in this one and only place we have a reference to lapack in module_list.py. So if we continue to support that particular binding we need to pull lapack as well.

comment:17 Changed 7 years ago by fbissey

  • Authors set to Jean-Pierre Flori, François Bissey
  • Branch set to u/fbissey/17075
  • Commit set to 56d419e6eab697b4faf168ba177b3dff4090cbaf

Putting the conversion of ATLAS to .pc files here. I should commit the sage bits in a few hours.

New commits:

​56d419eClean ATLAS' spkg-install using Jean-Pierre's work. Make it output .pc files.

comment:18 follow-up: Changed 7 years ago by jpflori

Cannot this get in by itself? And the "sage bits" be put into other ticekts?

comment:19 Changed 7 years ago by fbissey

  • Status changed from new to needs_review

I am fine with that, nice and progressive. I am putting to need review then and you can play with it. I have only tried on OS X and my linux box will be off soon because the university has some power outage planned for the week end. No sage-on-gentoo development until Monday either because of that.

Hum, will have to change the description at some point.

comment:20 in reply to: ↑ 18 Changed 7 years ago by jdemeyer

Replying to jpflori:

Cannot this get in by itself? And the "sage bits" be put into other ticekts?

It doesn't really make sense to test just this ticket by itself. There should be at least one package using the new .pc file to shows that it actually works (either on this or a new ticket).

comment:21 Changed 7 years ago by vbraun

You can easily test it using pkgconfig. Its a strategic goal for us to clean up *blas linking. We should do what gets us fastest to that goal. How does doing more here or stacking tickets help us achieve that goal faster?

comment:22 follow-up: Changed 7 years ago by fbissey

I can import the sage-on-gentoo bits for sage quite easily (depends if we want to keep the library_dir bits which enable blas in odd location or not). To some extent that would be testable immediately. The various packages would probably need to be staged carefully. I am especially concerned by the python package - numpy and scipy in particular. Have to be careful how we feed those two and which way is easiest - Gentoo way is too complicated, I think we can do something easier.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 7 years ago by jpflori

Replying to fbissey:

I can import the sage-on-gentoo bits for sage quite easily (depends if we want to keep the library_dir bits which enable blas in odd location or not). To some extent that would be testable immediately. The various packages would probably need to be staged carefully. I am especially concerned by the python package - numpy and scipy in particular. Have to be careful how we feed those two and which way is easiest - Gentoo way is too complicated, I think we can do something easier.

I think in the end we want to allow users to use strange BLAS implems in strange places.

And for the numpy and scipy bits, can we work on top of what was done at #17630?

As Volker, I propose to merge this ticket asap and work on using the produced pc files for our spkg in follow up tickets and maybe make #17630 a task to be closed when everything is ported.

comment:24 Changed 7 years ago by fbissey

I am sorry I am not more active on this, I have a collection of issue pestering and I have trouble keeping any at the top. I'll add the stuff in question because it will be quick and easy but sage side I am more worried about fixing numpy 1.9.x to get it in. I have a number of Gentoo issue also pestering me (well for starter the blas infrastructure is broken in a Gentoo prefix coincidence I guess).

comment:25 in reply to: ↑ 23 Changed 7 years ago by jdemeyer

Replying to jpflori:

How does doing more here or stacking tickets help us achieve that goal faster?

By increasing the chances of somebody reviewing this ticket if they can actually see that it works.

The goal of Sage tickets is not just to write code, but to get it reviewed. A ticket without a working use-case is hard to test and therefore hard to review.

comment:26 Changed 7 years ago by jdemeyer

The ticket description doesn't seem to correspond with the code in the branch, can you please update the description?

comment:27 Changed 6 years ago by jpflori

Bumpy comment. What's the relation between Volker code and François branch? It would be very nice to use something else than a very outdated ATLAS in Sage :(

comment:28 follow-up: Changed 6 years ago by fbissey

Well, I have commented in a related ticket that I had been somewhat demotivated to work on this. I think most stuff has to be thrown away or re-based. Jeroen was working on an ATLAS upgrade more recently because of power8.

But really the plan is to get something like the functionality I have now in sage-on-gentoo:

  • you can use one of many blas/lapack
  • Each blas/lapack install some .pc file
  • we use the .pc file to find the libraries and headers needed

So the first step is get ATLAS to install .pc files, then migrate spkg to use them including the sage library. Then we can start writing alternative blas/lapack spkg.

comment:29 in reply to: ↑ 28 Changed 6 years ago by jdemeyer

Replying to fbissey:

Jeroen was working on an ATLAS upgrade more recently because of power8.

Right, but there are issues with the new ATLAS...

In any case, that upgrade does not involve the build system, so it's independent of this ticket here.

comment:30 Changed 6 years ago by vbraun

  • Branch changed from u/fbissey/17075 to u/vbraun/17075

comment:31 Changed 6 years ago by vbraun

  • Commit changed from 56d419e6eab697b4faf168ba177b3dff4090cbaf to 432eb258c5f1dc62a7eb50d54df82979894242cb
  • Description modified (diff)
  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

Rebased onto latest beta

This seems to work so lets merge it

New commits:

​432eb25Clean ATLAS' spkg-install using Jean-Pierre's work. Make it output .pc files.

comment:32 Changed 6 years ago by vbraun

  • Branch changed from u/vbraun/17075 to 432eb258c5f1dc62a7eb50d54df82979894242cb
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.