search

cschwan / sage-on-gentoo

(Unofficial) Gentoo Overlay for Sage- and Sage-related ebuilds
84 stars 26 forks source link

sci-libs/gsl-2.1[science] does not install gslcblas.pc #429

Closed strogdon closed 7 years ago

strogdon commented 8 years ago

This is probably a science-overlay bug. sage-on-gentoo requires >=sci-libs/gsl-1.16 but gsl-2.1 will not work. The symptom after installing gsl-2.1 and eselect cblas set gsl.

pkg-config --libs gsl
-lgsl
 pkg-config --libs cblas
-lgsl
pkg-config --libs gslcblas
Package gslcblas was not found in the pkg-config search path.
Perhaps you should add the directory containing `gslcblas.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gslcblas' found

and the symlink /usr/include/cblas.h is missing. This latter causes iml to fail. After installing gsl-2.1 and then downgrading to gsl-1.16-r2 the /usr/include/cblas.h symlink is still missing even though eselect cblas list returns gsl as the current cblas - eselect cblas set gsl then restores the symlink.

kiwifb commented 8 years ago

Actually upstream is using 2.1 but yes it looks like something is faulty with gsl 2.1 to use it as cblas. I'll have a look.

strogdon commented 8 years ago

Also, the installed gsl.pc file is probably not correct. I believe one should get

 pkg-config --libs gsl
-lgsl -lgslcblas -lm
kiwifb commented 8 years ago

Embarrassing I have gsl 2.1 installed from a private overlay. Scouting for differences.

strogdon commented 8 years ago

It looks like gsl 2.1 uses numeric-int64-multibuild.eclass from science overlay.

kiwifb commented 8 years ago

It does and it has the useflag cblas-external I am building stuff to see what happens, since when do I have multi-abi enabled, I'll have to check that.

kiwifb commented 8 years ago

OK it looks like if have USE=cblas-external, libgslcblas is still produced but none of the alternative files to switch to gsl as a cblas provider are installed. But then gsl.pc looks like:

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
GSL_CBLAS_LIB=-lopenblas_threads 

Name: GSL
Description: GNU Scientific Library
Version: 2.1
Libs: -L/usr/lib64 -lgsl ${GSL_CBLAS_LIB} -lm -lm 
Cflags: -I/usr/include

so pkg-config --libs gsl should have a cblas in it. Looking at the other scenario with cblas-external disabled.

kiwifb commented 8 years ago

Outcome seems to be what I expect (or almost) for USE=-cblas-external

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
GSL_CBLAS_LIB=-lgslcblas

Name: GSL
Description: GNU Scientific Library
Version: 2.1
Libs: -L/usr/lib64 -lgsl ${GSL_CBLAS_LIB} -lm -lm 
Cflags: -I/usr/include

and the alternative files are there. It is a bit dubious in my opinion to cblas.pc point to gsl.pc but I guess it works. So it looks like you have an incorrect gsl.pc for some reason. Can you post it?

kiwifb commented 8 years ago

Ha! USE="-cblas-external -int64" produce an incorrect gsl.pc:

prefix="/usr"
exec_prefix="/usr"
libdir="/usr/lib64"
includedir="/usr/include"

Name: gsl
Description: GNU Scientific Library CBLAS implementation
Version: 2.1
URL: http://www.gnu.org/software/gsl/
Requires: 
Requires.private: 
Conflicts: 
Libs: -L"/usr/lib64" -L${libdir} -lgsl
Libs.private: -lm
Cflags: -I"/usr/include" -I${includedir}

And I believe that's what you have.

strogdon commented 8 years ago

Yes, that's what I have.

kiwifb commented 8 years ago

The gsl.pc files should be identical, at least output wise, for USE="-cblas-external int64" and USE="-cblas-external -int64" but clearly they are not. Definitely a science overlay bug. Still trying to track it. Should open a matching issue for the science overlay.

Temporary fix is to have USE=int64 added for gsl.

kiwifb commented 8 years ago 
        if ! numeric-int64_is_static_build; then
            create_pkgconfig \
                --name  ${profname} \
                --description "${DESCRIPTION} CBLAS implementation" \
                --libs "-L\${libdir} -l${libname}" \
                --libs-private "-lm" \
                --cflags "-I\${includedir} $(numeric-int64_get_fortran_int64_abi_fflags)" \
                ${profname}
        fi

must be run for int32 only build when it shouldn't - it should only run for int64 builds. I am not sure what is the logic that leads to that happening.

strogdon commented 8 years ago

Do you get?

>>> Installing (1 of 1) sci-libs/gsl-2.1::science
>>> needed    sym /storage/strogdon/gentoo-rap/usr/lib64/libgsl.so.0
>>> needed    obj /storage/strogdon/gentoo-rap/usr/lib64/libgsl.so.0.17.0
!!! Error: Can't load module cblas-int64

This is in prefix.

kiwifb commented 8 years ago

I thought that was fixed :(

kiwifb commented 8 years ago

Did you have both -cblas-external and int64 in your useflags?

strogdon commented 8 years ago

Yes

[I] sci-libs/gsl
     Available versions:  1.14 1.16 1.16-r2[1] 2.1(0/19) 2.1(0/19)[1] {cblas-external int64 static-libs ABI_X86="32 64"}
     Installed versions:  2.1[1](02:15:33 AM 06/22/2016)(int64 -cblas-external -static-libs ABI_X86="64 -32")
     Homepage:            http://www.gnu.org/software/gsl/
     Description:         GNU Scientific Library

[1] "science" /storage/strogdon/gentoo-prefix/var/lib/layman/science
kiwifb commented 8 years ago

This needs to go to the science overlay. That's at least two bugs. Then there would be a question of intent. gslcblas should be a separate thing from gsl in my opinion but the added complexity may be too much to handle.

strogdon commented 8 years ago

With -cblas-external and int64 useflags

pkg-config --libs cblas
-lgsl -lgslcblas -lm

I think this should only be -lgslcblas for my cblas and there is no /usr/include/cblas.h symlink

kiwifb commented 8 years ago

See earlier comments, cblas.pc is linked to gsl.pc - terrible but you have to redesign things to separate the two. It is the correct thing to do of course.

kiwifb commented 8 years ago

The header is indeed missing. Potentially a third bug (fourth if we count separation of gslcblas).

strogdon commented 8 years ago

Perhaps not the most correct thing, but I think a gsl-2.1 ebuild could be designed around that of gsl-1.16-r2

kiwifb commented 8 years ago

I think I just nuked my private version of gsl-2.1 based on gsl-1.6-r2 from my private overlay :( Shouldn't be hard to redo anyway.

kiwifb commented 8 years ago

I see, 1.6-r2 doesn't support int64 and I am not sure why the useflag has been added since there is no library for int64 generated and the one pointed to by gsl-int64.pc doesn't exist. Who commited this mess.

strogdon commented 8 years ago

I seems to work here if I move gsl-1.16-r2 to my local overlay as gsl-2.1 and add alternatives-2.eclass

kiwifb commented 8 years ago

I am preparing a new ebuild to submit as a PR to the scence overlay. Copying 1.6-r2 to 2.1 won't be allowed because it is EAPI 5 and they will only accept EAPI 6 in, unless there is a compelling reason to do otherwise. I think the int64 stuff was added as a "cheap" way to get there. Do you have a 32bit machine anywhere? Not just a multi-abi machine, something that boots as x86 rather than x86_64. There is a test in gsl 2.1 that fails in 32 bits ABI when I build multi abi on my x86_64 machine. That's numerical precision stuff of numbers close to zero.

strogdon commented 8 years ago

Sorry, I don't have a 32 bit machine anymore.

kiwifb commented 8 years ago

Not just me I will adopt http://pkgs.fedoraproject.org/cgit/rpms/gsl.git/diff/gsl-tol.patch?id=b08d2756bf081ed602efa709edad9dfcf13b1122

kiwifb commented 8 years ago

Turns out it doesn't fix my problem.

kiwifb commented 8 years ago

Will still go on with the PR soon because the current ebuild has the same problem anyway.