Opened 8 years ago
Last modified 6 years ago
#17635 closed enhancement
Update Givaro, FFLAS-FFPACK and LinBox — at Version 110
Reported by: | jpflori | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-7.4 |
Component: | packages: standard | Keywords: | linbox, givaro, fflas-ffpack, sd75 |
Cc: | fbissey, cpernet | Merged in: | |
Authors: | Clement Pernet, Jeroen Demeyer | Reviewers: | François Bissey |
Report Upstream: | N/A | Work issues: | |
Branch: | u/fbissey/givaro_fflasffpack_linbox (Commits, GitHub, GitLab) | Commit: | 8cd62e2c23a99466c9d22034d6a0d2db267ea771 |
Dependencies: | #20237 | Stopgaps: |
Description (last modified by )
Tarballs of released packages (with appropriate names) can be found at:
Change History (111)
comment:1 Changed 8 years ago by
comment:2 follow-up: ↓ 3 Changed 8 years ago by
- Cc fbissey added
So we have to wait for linbox? Do we have an idea of when it will happen?
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 8 years ago by
Replying to fbissey:
So we have to wait for linbox? Do we have an idea of when it will happen?
Yes we have to wait for a new Linbox, expected about the end of february, Clément Pernet wrote me, together with updated Givaro and fflas-ffpack.
By the way, I started this for #17630 which might interest you as well, I'll push code there tomorrow.
comment:4 in reply to: ↑ 3 Changed 7 years ago by
- Description modified (diff)
- Milestone changed from sage-6.5 to sage-6.7
- Summary changed from Update Givaro to 3.8.0 to Update Givaro, FFLAS-FFPACK and LinBox
Replying to jpflori:
Replying to fbissey:
So we have to wait for linbox? Do we have an idea of when it will happen?
Yes we have to wait for a new Linbox, expected about the end of february, Clément Pernet wrote me, together with updated Givaro and fflas-ffpack.
It's June already...
Since givaro, LinBox and FFLAS-FFPACK all depend on each other, we should make one ticket.
comment:5 Changed 7 years ago by
- Description modified (diff)
- Milestone changed from sage-6.7 to sage-6.8
comment:6 follow-up: ↓ 8 Changed 7 years ago by
- Cc cpernet added
Sorry for the delay in releasing the fflas-ffpack/Givaro/LinBox environment. We're working on it now, and I'll keep you posted about the status. It should happen before the end of the year and hopefully much earlier.
I also meant to propose to replace ATLAS by OpenBLAS in sage. Looking at your clean-up work of the BLAS in #17630, I understand that we should proceed in the following order:
- release linbox
- upgrade linbox fflas-ffpack Givaro in Sage (this ticket #17635)
- clean-up the BLAS usage #17630
- replace ATLAS by OpenBLAS (ticket to be created)
I'll be happy to help in these tasks.
comment:7 Changed 7 years ago by
Let me remind you also about #15535, which pops up regularly. I don't know if it's a bug in Linbox or in the way that Sage uses Linbox, but it would be good to have a Linbox developer look at it.
comment:8 in reply to: ↑ 6 Changed 7 years ago by
Replying to cpernet:
Sorry for the delay in releasing the fflas-ffpack/Givaro/LinBox environment. We're working on it now, and I'll keep you posted about the status. It should happen before the end of the year and hopefully much earlier.
I also meant to propose to replace ATLAS by OpenBLAS in sage. Looking at your clean-up work of the BLAS in #17630, I understand that we should proceed in the following order:
- release linbox
- upgrade linbox fflas-ffpack Givaro in Sage (this ticket #17635)
- clean-up the BLAS usage #17630
- replace ATLAS by OpenBLAS (ticket to be created)
I'll be happy to help in these tasks.
I'll admit to have been a bit demotivated on the blas cleaning front. The tickets needs re-organizing and have good descriptions so we know what is supposed to go in them. Getting ATLAS
to produce .pc
file and using them is probably a priority task. Once that's done someone could create an optional openblas
spkg or something.
comment:9 follow-ups: ↓ 11 ↓ 12 Changed 7 years ago by
- Dependencies set to 18323
I'm working on it, and will release a new version of the 3 libs for the occasion, so as to ensure a smoother integration upstream. This will very likely be givaro-4.0.1 fflas-ffpack-2.2.0 linbox-1.4.1
These libraries now require c++11 support and this tickets therefore depends on #18323.
Inspired by what's propose in there, I suggest to add lines of the form
+# distutils: extra_compile_args = -std=c++11
to libs/linbox/linbox.pxd lib/linbox/fflas.pxd lib/linbox/echelonform.pxd but I understand that this is subject to a debate on sage-devel https://groups.google.com/forum/#!topic/sage-devel/aGwotQA9to8
If this option happens to be accepted, we would then need to add more cflags in the list: namely those produced by fflas-ffpack configure related to the target architecture:
-mavx -msse4.1
and others like -fabi-version=6 -fopenmp
.
I could not figure a way to append the string returned by bin/fflas-ffpack-config --cflags
to these pxd files. Any hint?
comment:10 Changed 7 years ago by
- Dependencies changed from 18323 to #18323
comment:11 in reply to: ↑ 9 Changed 7 years ago by
Replying to cpernet:
I could not figure a way to append the string returned by
bin/fflas-ffpack-config --cflags
to these pxd files. Any hint?
Add a definition in module_list.py
, you define a LINBOX_FLAGS
. It would be easier if you had a .pc
file as we have a python interface to pkgconfig
that we can use easily. Here you have to do your own parsing from python. Anyway you can then use LINBOX_FLAGS
in the .pxd
file.
comment:12 in reply to: ↑ 9 ; follow-up: ↓ 13 Changed 7 years ago by
Replying to cpernet:
-mavx -msse4.1
I understand that the libraries themselves want these, but why the Cython files?
and others like
-fabi-version=6
This looks like it should be used always for all C++ files then. Mixing ABI's doesn't look like a good idea.
-fopenmp
Same question as before, is this really needed for the Cython interface?
comment:13 in reply to: ↑ 12 Changed 7 years ago by
Replying to jdemeyer:
Replying to cpernet:
-mavx -msse4.1
I understand that the libraries themselves want these, but why the Cython files?
fflas-ffpack and linbox are essentially source libraries, so when you include the headers, you include the whole code. This is by design, due to the ubiquity of template programming in these libraries.
Now the old linbox-sage interface compiles some specializations and offer them through a C api. These extra flags would not be required if we would stick to using this interface.
But, since then, Cython started to offer the capability to hook C++ code directly and more functionnalities have been added in sage where fflas-ffpack code is called directly, like in libs/linbox/fflas.pxd where the C++ routine FFLAS::fgemm is called.
and others like
-fabi-version=6
This looks like it should be used always for all C++ files then. Mixing ABI's doesn't look like a good idea.
Sure. Maybe one should change the ABI higher up then.
-fopenmp
Same question as before, is this really needed for the Cython interface?
Same answer as above.
comment:14 Changed 7 years ago by
- Dependencies changed from #18323 to #19298
comment:15 Changed 7 years ago by
- Branch set to u/cpernet/givaro_fflasffpack_linbox
comment:16 follow-up: ↓ 17 Changed 7 years ago by
- Commit set to dd81c26b4ece4e206e5c3eb8c42e5a22337bc458
I added my working branch to the ticket. I could not find if and where I should store the tarballs of the new spkg?
As of today (sept 28 2015); they correspond to the upstream version of the 3 libs: givaro, fflas-ffpack and linbox.
I added .pc files for givaro and fflas-ffpack (coming soon for linbox), and defined the extra_compile_flages in modules_list.py
as suggested by fbissey.
This is still work in progress:
- LinBox sparse solver make the test-suite fail: I'm investigating the problem, which I could not reproduce in LinBox for the moment.
- the extra_compile_flags should be inferred from the .pc files (harcoded for the moment). I did not find how to use pkg-config through python to do it.
New commits:
dd81c26 | Update givaro to v4.0.1 fflas-ffpack to v2.2.0 and linbox to v1.4.1rc0.
|
comment:17 in reply to: ↑ 16 Changed 7 years ago by
Replying to cpernet:
I could not find if and where I should store the tarballs of the new spkg?
Just add a link to the upstream tarballs on this ticket. If any renaming is needed, you should rename the tarball and add a link to the renamed tarball.
comment:18 Changed 7 years ago by
- Description modified (diff)
comment:19 Changed 7 years ago by
- Commit changed from dd81c26b4ece4e206e5c3eb8c42e5a22337bc458 to c97f54702ff9273a6fd17954aa3578198300124c
Branch pushed to git repo; I updated commit sha1. New commits:
c97f547 | update fflas-givaro-linbox spkg version and minor chnages to configuration files
|
comment:20 Changed 7 years ago by
Instead of adding flags to individual extensions, they should be added to the .pxd
or .pyx
files.
comment:21 follow-up: ↓ 23 Changed 7 years ago by
Ok, now I get confused: fbissey suggested to define all compilation flags in module_list.py
. I saw there that most spkg related extension had their flags set in this file: e.g. flint, fplll, Lfunction, m4ri, m4rie...
Hence I moved all flags that I originally wrote in the linbox.pxd fflas-ffpack.pxd givaro.pxd
files to module_list.py
which has the advantage of defining everything at the same place.
Jeroen or François are you suggesting that the proper way to proceed is to
- define the flags
givaro_extra_compile_args
,fflas_ffpack_extra_compile_args
,linbox_extra_compile_args
inmodule_list.py
- use them in the pxd files with something like
+# distutils: extra_compile_args = ${givaro_extra_compile_args}
? Will do, if that's the way to go.
Also, I did not find how to invoque the python interface to pkgconfig, mentionned by françois.
comment:22 Changed 7 years ago by
Sorry I have been of the net for most of the week. For how to use pkgconfig
you can follow the way I use it for blas in sage-on-gentoo at https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/files/sage-6.8-blas-r1.patch. Note that you probably don't need to parse the library_dir
, I do it for blas in unusual location, which is expected for intel MKL or the AMD equivalent.
comment:23 in reply to: ↑ 21 Changed 7 years ago by
Replying to cpernet:
I moved all flags that I originally wrote in the
linbox.pxd fflas-ffpack.pxd givaro.pxd
files tomodule_list.py
Please don't!
which has the advantage of defining everything at the same place.
...but the disadvantage of requiring to add the flags to every single extension, which is much less scalable.
Jeroen or François are you suggesting that the proper way to proceed is to
- define the flags
givaro_extra_compile_args
,fflas_ffpack_extra_compile_args
,linbox_extra_compile_args
inmodule_list.py
- use them in the pxd files with something like
+# distutils: extra_compile_args = ${givaro_extra_compile_args}
Essentially yes. You can grep for GSL_LIBRARIES
to see how it's supposed to be done.
comment:24 Changed 7 years ago by
- Commit changed from c97f54702ff9273a6fd17954aa3578198300124c to fb16751ee2a275d55bef8824ee606fdd98f817f8
Branch pushed to git repo; I updated commit sha1. New commits:
fb16751 | Pass the library specific cflags in the pxd files instead of extensions in module_list.py
|
comment:25 follow-up: ↓ 28 Changed 7 years ago by
This is still not quite what I meant.
For example, why does src/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pxd
need GIVARO_CFLAGS
? Looking at that file, there is nothing related to givaro.
I assume you added GIVARO_CFLAGS
because it still somehow indirectly includes Givaro code. But then you should add GIVARO_CFLAGS
in the place where the Givaro headers are actually included and Cython's dependency tracking should pick it up.
See again the GSL_LIBRARIES
example: I don't add GSL_LIBRARIES
to every module which somehow indirectly uses GSL, only where the library functions are actually declared.
comment:26 Changed 7 years ago by
- Commit changed from fb16751ee2a275d55bef8824ee606fdd98f817f8 to c25de3330e09067dff47ecd8330df5ba7a00746e
Branch pushed to git repo; I updated commit sha1. New commits:
c25de33 | Remove all unecessary extra_compile_args for GIVARO and FFLASFFPACK.
|
comment:27 Changed 7 years ago by
- Commit changed from c25de3330e09067dff47ecd8330df5ba7a00746e to 73cc6b328406860fad586dea893625bac3f7f1fa
Branch pushed to git repo; I updated commit sha1. New commits:
73cc6b3 | Finds GIVARO and FFLASFFPACK CFLAGS in the .pc pkgconfig file.
|
comment:28 in reply to: ↑ 25 Changed 7 years ago by
Replying to jdemeyer:
I assume you added
GIVARO_CFLAGS
because it still somehow indirectly includes Givaro code. But then you should addGIVARO_CFLAGS
in the place where the Givaro headers are actually included and Cython's dependency tracking should pick it up.
Yes. It was necessary to add these flags to extensions when everything was gathered in module_list.py, but no longer now that it is in each pxd files. I now see the point! Sorry for messing this up, it's fixed. I also made the CFLAGS variables set by the pkgconfig .pc files, as suggested by François.
One pb remains: there is no gmp.pc for the moment, and the givaro.pc lists gmp as a dependency. Similarly fflas-ffpack.pc should list blas as dependency, but we still don't have a blas.pc file (see #17075). I suggest to remove these dependencies for the moment, and I'll add them once we have the proper .pc files. If you confirm, I'll produce new tar.gz for givaro and fflas-ffpack accordingly.
comment:29 Changed 7 years ago by
- Commit changed from 73cc6b328406860fad586dea893625bac3f7f1fa to 7fd9523fad7dd778ee1d42c803b06f103ccdd709
Branch pushed to git repo; I updated commit sha1. New commits:
7fd9523 | Add link flags for fflas-ffpack.
|
comment:30 Changed 7 years ago by
Are there any significant API changes in the new linbox? I would like to add a linbox interface for sparse matrices over ZZ. I could do that using the current linbox-1.3.2 but I'd like to know that it will still work after upgrading linbox.
comment:31 Changed 6 years ago by
- Branch changed from u/cpernet/givaro_fflasffpack_linbox to u/jdemeyer/givaro_fflasffpack_linbox
comment:32 Changed 6 years ago by
- Commit changed from 7fd9523fad7dd778ee1d42c803b06f103ccdd709 to c4473522fac04f2726d7406b9fbf2fdcd0796f8b
- Dependencies #19298 deleted
- Milestone changed from sage-6.8 to sage-7.1
Merged latest beta.
New commits:
c447352 | Merge tag '7.1.beta3' into t/17635/givaro_fflasffpack_linbox
|
comment:33 Changed 6 years ago by
- Commit changed from c4473522fac04f2726d7406b9fbf2fdcd0796f8b to f31752c6865b53eeef48d4fc7a46280823a7494e
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
f31752c | Merge tag '7.1.beta3' into t/17635/givaro_fflasffpack_linbox
|
comment:34 Changed 6 years ago by
fflas_ffpack
doesn't build:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../fflas-ffpack/utils/ -I../../fflas-ffpack/fflas/ -I../../fflas-ffpack/ffpack -I../../fflas-ffpack/field -I/usr/local/src/sage-git/local/include -I/usr/local/src/sage-git/local//include -D__FFLASFFPACK_HAVE_CBLAS -msse4.1 -mavx -fabi-version=6 -fopenmp -O2 -Wall -DNDEBUG -UFFLASFFPACK_DEBUG -g -O2 -fPIC -std=gnu++11 -c fflas_L1_inst.C -fPIC -DPIC -o .libs/fflas_L1_inst.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../fflas-ffpack/utils/ -I../../fflas-ffpack/fflas/ -I../../fflas-ffpack/ffpack -I../../fflas-ffpack/field -I/usr/local/src/sage-git/local/include -I/usr/local/src/sage-git/local//include -D__FFLASFFPACK_HAVE_CBLAS -msse4.1 -mavx -fabi-version=6 -fopenmp -O2 -Wall -DNDEBUG -UFFLASFFPACK_DEBUG -g -O2 -fPIC -std=gnu++11 -c fflas_L3_inst.C -fPIC -DPIC -o .libs/fflas_L3_inst.o In file included from ../../fflas-ffpack/fflas/fflas_sparse/csr.h:89:0, from ../../fflas-ffpack/fflas/fflas_sparse.h:126, from ../../fflas-ffpack/fflas/fflas.h:164, from fflas_L1_inst.C:34: ../../fflas-ffpack/fflas/fflas_sparse/csr/csr_pspmm.inl:48:2: error: stray '#' in program PAR_BLOCK{ ^
comment:35 Changed 6 years ago by
- Branch changed from u/jdemeyer/givaro_fflasffpack_linbox to u/cpernet/givaro_fflasffpack_linbox
comment:36 Changed 6 years ago by
- Commit changed from f31752c6865b53eeef48d4fc7a46280823a7494e to 4cd2289c8711642d448883ee6d843524ed5da5d5
- Description modified (diff)
I've updated the tarballs of the 3 libraries to the latests rc1 (the failing code in longer there) and updated the checksums. Everything builds on my box.
New commits:
db82895 | Patch merged upstream in fflas-ffpack
|
a45e379 | missing coma
|
4cd2289 | updating givaro, fflas-ffpack and linbox to latest rc1 version
|
comment:37 Changed 6 years ago by
- Description modified (diff)
comment:38 Changed 6 years ago by
- Description modified (diff)
comment:39 Changed 6 years ago by
On powerpc64le
, I had to kill the Givaro test test-rmint_inv_
after 11 hours. I don't think the test is supposed to take that long...
comment:40 Changed 6 years ago by
Thanks for raising this one. Bug reported on givaro's issue tracker: https://github.com/linbox-team/givaro/issues/6
Currently looking for an acces to a ppc64el to debug it.
The part of givaro that fails, recint, does small lenght multi-precision arithmetic, and very likely triggers endianness issues. Note that this part of the library is not currently used in sage neither directly nor through fflas-ffpack and linbox. However we'd like to have it fixed anyway, in order to update givaro's debian package.
comment:41 follow-up: ↓ 43 Changed 6 years ago by
On the same machine, fflas-ffpack
also fails: https://github.com/linbox-team/fflas-ffpack/issues/16
comment:42 Changed 6 years ago by
Apart from the build failures on some systems, are there any further obstructions to this ticket?
comment:43 in reply to: ↑ 41 ; follow-ups: ↓ 44 ↓ 45 Changed 6 years ago by
Replying to jdemeyer:
On the same machine,
fflas-ffpack
also fails: https://github.com/linbox-team/fflas-ffpack/issues/16
Fixed in https://github.com/linbox-team/fflas-ffpack/commit/8634b80bd0c20c538faf9471c8e2289c5a50a925
Replying to jdemeyer:
Apart from the build failures on some systems, are there any further obstructions to this ticket?
Apart from these, no obstruction on our side.
comment:44 in reply to: ↑ 43 Changed 6 years ago by
Replying to cpernet:
Apart from these, no obstruction on our side.
So why was this ticket never set to "needs_review" then?
comment:45 in reply to: ↑ 43 Changed 6 years ago by
Replying to cpernet:
Replying to jdemeyer:
On the same machine,
fflas-ffpack
also fails: https://github.com/linbox-team/fflas-ffpack/issues/16Fixed in https://github.com/linbox-team/fflas-ffpack/commit/8634b80bd0c20c538faf9471c8e2289c5a50a925
Do you plan to release fflas_ffpack-2.2.0rc2 for this? Or should we just use git master?
comment:46 follow-up: ↓ 48 Changed 6 years ago by
- the bug of Givaro on powerpc64le has been fixed upstream : https://github.com/linbox-team/givaro/issues/6
- yes I will cut a rc2 for both givaro and fflas-ffpack, if not a release.
- I did not put the need_review as there was still a hanging question about the blas.pc file and gmp.pc. I assume we will do without these files for the moment.
comment:47 Changed 6 years ago by
comment:48 in reply to: ↑ 46 Changed 6 years ago by
Replying to cpernet:
- I did not put the need_review as there was still a hanging question about the blas.pc file and gmp.pc.
I see. However, did anything change compared to earlier versions of these packages regarding compilation? If not and it worked before, it should still work...
comment:49 Changed 6 years ago by
As far as build and compilation is concerned, nothing changed. I'm checking a last few things on the linbox side (test suite fails badly on power8). Then I'd like to release this evening or tomorow and put this ticket in needs_review status.
comment:50 Changed 6 years ago by
- Description modified (diff)
comment:51 Changed 6 years ago by
- Commit changed from 4cd2289c8711642d448883ee6d843524ed5da5d5 to f82a77dc434c9e0c93aac406f239285cc140295a
Branch pushed to git repo; I updated commit sha1. New commits:
f82a77d | Update checksums to the latests released packages
|
comment:52 Changed 6 years ago by
- Status changed from new to needs_review
Givaro, fflas-ffpack and linbox have just been released: https://groups.google.com/forum/#!topic/linbox-devel/6dIj_HW3k38
I updated the link in the ticket descriptions to the latest tarball and updated the checksums.
This ticket is now ready for review.
comment:53 Changed 6 years ago by
Before passing to other details for this ticket, is everyone ok with linbox having openmp enabled?
comment:54 Changed 6 years ago by
Actually both fflas-ffpack
and linbox
, fflas-ffpack
has openmp enabled by default and it is stated explicitly in linbox
. Our minmal compiler should have openmp support, I am wondering about unintended consequences. In sage-on-gentoo I am now using openblas
with threads rather than openmp as I got into trouble with it.
comment:55 follow-up: ↓ 56 Changed 6 years ago by
Eventhough openmp is enabled in fflas-ffpack̀
and linbox
, the current code called by sage does not use any OpenMP parallelism.
If you think it is necessary, I could pass the --disable-open
argument to the configure scripts. Thanks for pointing out that linbox still forces the -fopenmp evenif --disable-omp was passed to configure. We'll fix it.
Regarding the use of a threaded BLAS: it is possible to run the sequential code of fflas-ffpack
on top of a parallel BLAS, but one will achieve much better performances by running the parallel code of fflas-ffpack
(with OpenMP enabled) on top of a sequential BLAS. This will need further discussions when we'll want to have sage run its linear algebra kernels in parallel.
comment:56 in reply to: ↑ 55 Changed 6 years ago by
Replying to cpernet:
Eventhough openmp is enabled in
fflas-ffpack̀
andlinbox
, the current code called by sage does not use any OpenMP parallelism.
Yes
If you think it is necessary, I could pass the
--disable-open
argument to the configure scripts.
At this stage I think that's an unknown that will only be determined by experience.
Thanks for pointing out that linbox still forces the -fopenmp evenif --disable-omp was passed to configure. We'll fix it.
I haven't looked at linbox
' configure.ac
yet so I don't know about that. I only noticed that it for fflas-ffpack
it is the default if you don't pass anything.
Regarding the use of a threaded BLAS: it is possible to run the sequential code of
fflas-ffpack
on top of a parallel BLAS, but one will achieve much better performances by running the parallel code offflas-ffpack
(with OpenMP enabled) on top of a sequential BLAS. This will need further discussions when we'll want to have sage run its linear algebra kernels in parallel.
Sure.
comment:57 Changed 6 years ago by
I had a concern that there may be linking issue on cygwin because of libgomp. But -fopenmp
should be in the CFLAGS
provided by fflas-ffpack.pc
. So long as those flags are passed to the linker I guess we should be ok.
@jpflori can you comment on the linking needs on cygwin?
comment:58 follow-up: ↓ 60 Changed 6 years ago by
OK, more thoughts about fflas-ffpack
. By default usage of sse4.1
, avx
, avx2
and fma
instructions are enabled if found. This is a problem when building a binary for redistribution as we cannot guarantee that the target machine will support any instructions found on the building machine. We need to be able to disable those for binary build (SAGE_FAT_BINARY=yes
?).
Going through linbox
now. Like fflas-ffpack
, openmp
is enabled by default even without --enable-openmp
in spkg-install
but it looks like it can be disable the standard way to me. linbox
looks for
LB_CHECK_IML LB_CHECK_M4RI LB_CHECK_M4RIE LB_CHECK_MPFR # we nedd mpfr next : LB_CHECK_FPLLL LB_CHECK_FLINT LB_CHECK_NTL
but none of these are in linbox
's dependencies. Are any of those actually used?
Actually the current version should depend on ntl
and iml
(sage-sh) fbissey@QCD-nzi3:sage-7.0$ ldd -r local/lib/liblinboxsage.so.0.0.0 linux-vdso.so.1 (0x00007ffcaf131000) libgmpxx.so.8 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgmpxx.so.8 (0x00007f3f89ea8000) libgmp.so.16 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgmp.so.16 (0x00007f3f89c31000) libntl.so.19 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libntl.so.19 (0x00007f3f89810000) libcblas.so.3 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libcblas.so.3 (0x00007f3f895ed000) libatlas.so.3 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libatlas.so.3 (0x00007f3f88d01000) liblinbox.so.0 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/liblinbox.so.0 (0x00007f3f88afa000) libgivaro.so.0 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgivaro.so.0 (0x00007f3f8889d000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 (0x00007f3f88557000) libm.so.6 => /lib64/libm.so.6 (0x00007f3f88253000) libc.so.6 => /lib64/libc.so.6 (0x00007f3f87eb8000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 (0x00007f3f87ca0000) libgf2x.so.1 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgf2x.so.1 (0x00007f3f87a8a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3f8786d000) /lib64/ld-linux-x86-64.so.2 (0x0000561bc940b000) undefined symbol: maxMagnMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: findRNS (local/lib/liblinboxsage.so.0.0.0) undefined symbol: RNSbound (local/lib/liblinboxsage.so.0.0.0) undefined symbol: certSolveMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: certSolveRedMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: nonsingSolvLlhsMM (local/lib/liblinboxsage.so.0.0.0) undefined symbol: nonsingSolvRNSMM (local/lib/liblinboxsage.so.0.0.0)
compared to sage-on-gentoo on the same machine
ldd -r /usr/lib64/liblinboxsage.so.0.0.0 linux-vdso.so.1 (0x00007ffe013bb000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00007f8a84d7a000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8a84b09000) libntl-9.6.2.so => /usr/lib64/libntl-9.6.2.so (0x00007f8a846e5000) libreflapack.so => /usr/lib64/libreflapack.so (0x00007f8a83f03000) libopenblas_threads.so.0 => /usr/lib64/libopenblas_threads.so.0 (0x00007f8a8396b000) liblinbox.so.0 => /usr/lib64/liblinbox.so.0 (0x00007f8a83763000) libgivaro.so.0 => /usr/lib64/libgivaro.so.0 (0x00007f8a83507000) libiml.so.0 => /usr/lib64/libiml.so.0 (0x00007f8a832e6000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 (0x00007f8a82fd6000) libm.so.6 => /lib64/libm.so.6 (0x00007f8a82cd2000) libc.so.6 => /lib64/libc.so.6 (0x00007f8a82937000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 (0x00007f8a8271f000) libgf2x.so.1 => /usr/lib64/libgf2x.so.1 (0x00007f8a82509000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgfortran.so.3 (0x00007f8a821e0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a81fc4000) /lib64/ld-linux-x86-64.so.2 (0x00005557ec4cf000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libquadmath.so.0 (0x00007f8a81d85000)
Where I had to add LIBS="-liml"
for things to be completely resolved.
comment:59 Changed 6 years ago by
- Reviewers set to François Bissey
- Status changed from needs_review to needs_work
comment:60 in reply to: ↑ 58 ; follow-up: ↓ 61 Changed 6 years ago by
Replying to fbissey:
OK, more thoughts about
fflas-ffpack
. By default usage ofsse4.1
,avx
,avx2
andfma
instructions are enabled if found. This is a problem when building a binary for redistribution as we cannot guarantee that the target machine will support any instructions found on the building machine. We need to be able to disable those for binary build (SAGE_FAT_BINARY=yes
?).
Sure, we could do that. The alternative option would be to do as for the openblas deb package: have it include all kernel variants and let the switch happen dynamically depending on the variant of x86 it is run on. I am not very familiar with this technique and need to investigate how this can be built.
Going through
linbox
now. Likefflas-ffpack
,openmp
is enabled by default even without--enable-openmp
inspkg-install
but it looks like it can be disable the standard way to me.
Yes it can, but in linbox
it will still pass a -fopenmp
argument to g++ even if you passed the --disable-openmp
option at configure time. You made me find it yesterday, and this is now https://github.com/linbox-team/linbox/issues/24.
linbox
looks forLB_CHECK_IML LB_CHECK_M4RI LB_CHECK_M4RIE LB_CHECK_MPFR # we nedd mpfr next : LB_CHECK_FPLLL LB_CHECK_FLINT LB_CHECK_NTLbut none of these are in
linbox
's dependencies. Are any of those actually used?
These are optional dependencies. The long term goal is to have linbox code that uses these libs when available. For the moment, I think they are mostly used for benchmarking comparisons, except for NTL, IML
and fplll
used here and there when available.
Passing the --with-all=
option to configure, as we do, will automatically enable all these optional dependencies if they are found. We could be more picky if this causes problems.
Actually the current version should depend on
ntl
andiml
(sage-sh) fbissey@QCD-nzi3:sage-7.0$ ldd -r local/lib/liblinboxsage.so.0.0.0 linux-vdso.so.1 (0x00007ffcaf131000) libgmpxx.so.8 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgmpxx.so.8 (0x00007f3f89ea8000) libgmp.so.16 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgmp.so.16 (0x00007f3f89c31000) libntl.so.19 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libntl.so.19 (0x00007f3f89810000) libcblas.so.3 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libcblas.so.3 (0x00007f3f895ed000) libatlas.so.3 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libatlas.so.3 (0x00007f3f88d01000) liblinbox.so.0 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/liblinbox.so.0 (0x00007f3f88afa000) libgivaro.so.0 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgivaro.so.0 (0x00007f3f8889d000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 (0x00007f3f88557000) libm.so.6 => /lib64/libm.so.6 (0x00007f3f88253000) libc.so.6 => /lib64/libc.so.6 (0x00007f3f87eb8000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 (0x00007f3f87ca0000) libgf2x.so.1 => /home/fbissey/sandbox/git-fork/sage-7.0/local/lib/libgf2x.so.1 (0x00007f3f87a8a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3f8786d000) /lib64/ld-linux-x86-64.so.2 (0x0000561bc940b000) undefined symbol: maxMagnMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: findRNS (local/lib/liblinboxsage.so.0.0.0) undefined symbol: RNSbound (local/lib/liblinboxsage.so.0.0.0) undefined symbol: certSolveMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: certSolveRedMP (local/lib/liblinboxsage.so.0.0.0) undefined symbol: nonsingSolvLlhsMM (local/lib/liblinboxsage.so.0.0.0) undefined symbol: nonsingSolvRNSMM (local/lib/liblinboxsage.so.0.0.0)compared to sage-on-gentoo on the same machine
ldd -r /usr/lib64/liblinboxsage.so.0.0.0 linux-vdso.so.1 (0x00007ffe013bb000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00007f8a84d7a000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8a84b09000) libntl-9.6.2.so => /usr/lib64/libntl-9.6.2.so (0x00007f8a846e5000) libreflapack.so => /usr/lib64/libreflapack.so (0x00007f8a83f03000) libopenblas_threads.so.0 => /usr/lib64/libopenblas_threads.so.0 (0x00007f8a8396b000) liblinbox.so.0 => /usr/lib64/liblinbox.so.0 (0x00007f8a83763000) libgivaro.so.0 => /usr/lib64/libgivaro.so.0 (0x00007f8a83507000) libiml.so.0 => /usr/lib64/libiml.so.0 (0x00007f8a832e6000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 (0x00007f8a82fd6000) libm.so.6 => /lib64/libm.so.6 (0x00007f8a82cd2000) libc.so.6 => /lib64/libc.so.6 (0x00007f8a82937000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 (0x00007f8a8271f000) libgf2x.so.1 => /usr/lib64/libgf2x.so.1 (0x00007f8a82509000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgfortran.so.3 (0x00007f8a821e0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a81fc4000) /lib64/ld-linux-x86-64.so.2 (0x00005557ec4cf000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libquadmath.so.0 (0x00007f8a81d85000)Where I had to add
LIBS="-liml"
for things to be completely resolved.
This seems correct: the sage-linbox interface only uses these 2 libs when found.
Are you saying that the -liml
option is not passed to gcc even when iml
was detected at configure time? This would be another bug then.
comment:61 in reply to: ↑ 60 Changed 6 years ago by
Replying to cpernet:
This seems correct: the sage-linbox interface only uses these 2 libs when found. Are you saying that the
-liml
option is not passed to gcc even wheniml
was detected at configure time? This would be another bug then.
Yes, at least it is the case in 1.3.6, I haven't confirmed yet it is the case in 1.4.0, but if you weren't aware of it then it is probably still the case. I would rather have ntl
and iml
at least be in the dependencies as it makes the build reproducible. Otherwise the libraries linked to linboxsage
will be random.
comment:62 follow-up: ↓ 63 Changed 6 years ago by
On POWER8, I get an internal compiler error while compiling fflas-ffpack
using GCC-4.9.3.
Clement, did you manage to compile fflas-ffpack
on sardonis? Do you use the system-installed GCC 4.9.2 or did you compile within Sage?
comment:63 in reply to: ↑ 62 Changed 6 years ago by
Replying to jdemeyer:
On POWER8, I get an internal compiler error while compiling
fflas-ffpack
using GCC-4.9.3.Clement, did you manage to compile
fflas-ffpack
on sardonis? Do you use the system-installed GCC 4.9.2 or did you compile within Sage?
Outch! I did compile with the system-installed gcc v 4.9.2 and did not hit any internal compiler error.
comment:64 Changed 6 years ago by
linbox
again, LB_OPT
is commented out in configure.ac
therefore --enable-optimization
which is still in spkg-install
is no longer a recognised option and should be removed unless it is an error upstream.
comment:65 Changed 6 years ago by
src/sage/rings/finite_rings/element_givaro.pxd
refers to givaro/givgfq.h
, which no longer exists.
comment:66 Changed 6 years ago by
On powerpc64le with GCC 5.3.0, all 3 packages build and pass their testsuite.
comment:67 Changed 6 years ago by
On my laptop (Linux tamiyo 3.17.7-gentoo #1 SMP PREEMPT Wed Dec 31 20:06:39 CET 2014 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux
), fflas_ffpack fails to build with GCC 4.8.4:
make[6]: Entering directory '/usr/local/src/sage-config/local/var/tmp/sage/build/fflas_ffpack-2.2.0/src/fflas-ffpack/interfaces/libs' /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../fflas-ffpack/utils/ -I../../../fflas-ffpack/fflas/ -I../../../fflas-ffpack/ffpack -I../../../fflas-ffpack/field -I/usr/local/src/sage-config/local/include -I/usr/local/src/sage-config/local//include -D__FFLASFFPACK_HAVE_CBLAS -msse4.1 -mavx -fabi-version=6 -fopenmp -O2 -Wall -DNDEBUG -UFFLASFFPACK_DEBUG -g -O2 -fPIC -std=gnu++11 -c -o fflas_L1_inst.lo fflas_L1_inst.C libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../fflas-ffpack/utils/ -I../../../fflas-ffpack/fflas/ -I../../../fflas-ffpack/ffpack -I../../../fflas-ffpack/field -I/usr/local/src/sage-config/local/include -I/usr/local/src/sage-config/local//include -D__FFLASFFPACK_HAVE_CBLAS -msse4.1 -mavx -fabi-version=6 -fopenmp -O2 -Wall -DNDEBUG -UFFLASFFPACK_DEBUG -g -O2 -fPIC -std=gnu++11 -c fflas_L1_inst.C -fPIC -DPIC -o .libs/fflas_L1_inst.o In file included from ../../../fflas-ffpack/fflas/fflas_fger_mp.inl:40:0, from ../../../fflas-ffpack/fflas/fflas.h:126, from fflas_L1_inst.C:34: ../../../fflas-ffpack/fflas/fflas_fgemm/fgemm_classical_mp.inl:204:2: error: stray '#' in program WAIT; ^ ../../../fflas-ffpack/fflas/fflas_fgemm/fgemm_classical_mp.inl: In function 'typename FFPACK::RNSInteger<T>::Element_ptr FFLAS::fgemm(const FFPACK::RNSInteger<T>&, FFLAS::FFLAS_TRANSPOSE, FFLAS::FFLAS_TRANSPOSE, size_t, size_t, size_t, typename FFPACK::RNSInteger<T>::Element, typename FFPACK::RNSInteger<T>::ConstElement_ptr, size_t, typename FFPACK::RNSInteger<T>::ConstElement_ptr, size_t, typename FFPACK::RNSInteger<T>::Element, typename FFPACK::RNSInteger<T>::Element_ptr, size_t, FFLAS::MMHelper<FFPACK::RNSInteger<T>, FFLAS::MMHelperAlgo::Classic, FFLAS::ModeCategories::DefaultTag, FFLAS::ParSeqHelper::Parallel<Cut, Param> >&)': ../../../fflas-ffpack/fflas/fflas_fgemm/fgemm_classical_mp.inl:204:8: error: expected ';' before string constant WAIT; ^ Makefile:576: recipe for target 'fflas_L1_inst.lo' failed make[6]: *** [fflas_L1_inst.lo] Error 1
Full log attached.
comment:68 Changed 6 years ago by
Some of the preprocessed code looks like
#pragma omp task shared(F) {fadd(F, rowsize, N, A+iter.begin()*lda, lda, B+iter.begin()*ldb, ldb, C+iter.begin()*ldc, ldc);;};;} } };};} #pragma omp taskwait ;; }
so I guess you're missing some newlines in certain macros.
comment:69 Changed 6 years ago by
- Branch changed from u/cpernet/givaro_fflasffpack_linbox to u/jdemeyer/givaro_fflasffpack_linbox
comment:70 Changed 6 years ago by
- Commit changed from f82a77dc434c9e0c93aac406f239285cc140295a to 6c253a017cc54fa7c6de861d6f093f5ffc9b875c
Due to https://github.com/linbox-team/linbox/issues/24 this does not actually work...
New commits:
6c253a0 | Disable openmp in fflas_ffpack
|
comment:71 Changed 6 years ago by
- Commit changed from 6c253a017cc54fa7c6de861d6f093f5ffc9b875c to 5dc9f122c6646c3edef0775f4c9896e42ca0e28a
Branch pushed to git repo; I updated commit sha1. New commits:
5dc9f12 | Disable openmp in linbox
|
comment:72 follow-up: ↓ 79 Changed 6 years ago by
Note that this ticket conflicts badly with #20133.
comment:73 Changed 6 years ago by
- Commit changed from 5dc9f122c6646c3edef0775f4c9896e42ca0e28a to 35c51905b5d78fee8895b63b12d59df829096473
comment:74 Changed 6 years ago by
- Commit changed from 35c51905b5d78fee8895b63b12d59df829096473 to b153b931cf977d038501d9643f05f15a2c6d3f03
Branch pushed to git repo; I updated commit sha1. New commits:
b153b93 | Put FFLASFFPACK_CFLAGS where the linbox headers are included
|
comment:75 Changed 6 years ago by
I got this to build properly now, but there are still a lot of doctest failures in finite field arithmetic :-(
Are there any significant API changes in Givaro that we should know about?
comment:76 Changed 6 years ago by
- Commit changed from b153b931cf977d038501d9643f05f15a2c6d3f03 to 402dd108855f27dba8f3c8c2a7d4d1f4c3385af0
Branch pushed to git repo; I updated commit sha1. New commits:
402dd10 | Reduce modulo characteristic before calling GFqDom::init()
|
comment:77 Changed 6 years ago by
- Status changed from needs_work to needs_review
comment:78 Changed 6 years ago by
- Commit changed from 402dd108855f27dba8f3c8c2a7d4d1f4c3385af0 to 186c233af73077c98bd4b373d0adc891d0221a8a
Branch pushed to git repo; I updated commit sha1. New commits:
186c233 | If SAGE_FAT_BINARY is set, disable all processor-specific optimizations
|
comment:79 in reply to: ↑ 72 Changed 6 years ago by
Replying to jdemeyer:
Note that this ticket conflicts badly with #20133.
Will have conflicts with #20140 if I add bits to the dependencies of linbox
. As mentioned earlier it has automagic dependencies on iml
, ntl
and now fplll
(to check) so you potentially get slightly different linbox
depending on the build order. I am uncomfortable with that.
comment:80 Changed 6 years ago by
- Dependencies set to #20140
- Status changed from needs_review to needs_work
I agree with your last comment.
comment:81 Changed 6 years ago by
I spent quite some today working on fflas-ffpack-2.2.0
for sage-on-gentoo, expect a PR shortly to fix the tests when fflas-ffpack
has been configured with --enable-precompilation
(not that the test will work if you previously installed fflas-ffpack
with --enable-precompilation
in a standard location - do I need to say more).
lapack
, and even probably ATLAS
' clapack interface, is detected properly but you have to pass all the libraries for lapack
and cblas
in the --with-blas-libs
switch. With our new .pc
files that should translate to
--with-blas-cflags="$(pkg-config cblas --cflags)" --with-blas-libs="$(pkg-config lapack --libs)"
Although it would probably be safer to put
--with-blas-cflags="$(pkg-config cblas --cflags)" --with-blas-libs="$(pkg-config lapack cblas blas --libs)"
in case lapack.pc
doesn't pull either or both cblas
and blas
.
sage
run spkg-check
after install (a bit daft but hard to fix with the current system) so we should also be ok to add a spkg-check
to fflas-ffpack
without including my upcoming PR.
comment:82 Changed 6 years ago by
Started on linbox
. iml
properly linked in this version if found. fplll
detected but nowhere to be seen in the final library and no missing fplll
symbols. On the other I have just been wacked by the detection of opencl
that I wasn't expecting. No -lOpenCL are passed to
liblinbox or
liblinboxsage` when linking when it should be. Let's disable it explicitly for the time being.
comment:83 Changed 6 years ago by
I have sent a request for some explanations to Clément for the linbox tarball, I have patched something and run autoreconf on it and the libraries I get out are completely different.
comment:84 Changed 6 years ago by
- Dependencies #20140 deleted
- Milestone changed from sage-7.1 to sage-7.2
comment:85 Changed 6 years ago by
Any news here? There have been various changes in how Sage uses pkgconfig
, should we try again to get this working?
comment:86 Changed 6 years ago by
Clement told me a couple of weeks ago he was on holidays. I also send a couple of PR for fflas-ffpack
and linbox
. He is supposed to cut new releases. I would prefer to wait for a new cut of linbox
at least as patching the one in the description and running autoreconf
on it lead to unexpected results (liblinbox
and liblinboxsage
were linked completely differently, WTF?).
comment:87 Changed 6 years ago by
- Dependencies set to #20237
comment:88 Changed 6 years ago by
- Commit changed from 186c233af73077c98bd4b373d0adc891d0221a8a to 02afed245727c89ecb7437534b7555d9e1b85d6c
comment:89 Changed 6 years ago by
Note that this merge is really more than just a merge: I also started using pkgconfig
similarly to the way how we started using it in Sage 7.1.
comment:90 Changed 6 years ago by
This branch builds fine and passes make ptestlong
for me.
comment:91 follow-up: ↓ 93 Changed 6 years ago by
Hi, Sorry for the delay. Just for the status report. I've produced fflas-ffpack-2.2.1rc0 and linbox-1.4.1rc0 (links available in the description of this ticket), where I tried to fix the remaining issues:
- fixing the disable-omp problem (issue https://github.com/linbox-team/linbox/issues/24)
- the missing line break in OMP macro (but it should not be a problem here, as we disable omp) (comment 67_68)
- removing the obsolete
--enable-optimization
of linbox (comment 64)
I still did not touch the opencl issue.
comment:92 Changed 6 years ago by
- Branch changed from u/jdemeyer/givaro_fflasffpack_linbox to u/cpernet/givaro_fflasffpack_linbox
comment:93 in reply to: ↑ 91 Changed 6 years ago by
- Commit changed from 02afed245727c89ecb7437534b7555d9e1b85d6c to ce91fb5c4af3d46c7d8cdeddfcfc7c2a8b31e69f
Replying to cpernet:
links available in the description of this ticket
No, they are not.
New commits:
608717f | remove obsolete --enable-optimization
|
b6b60be | Merge branch 'u/jdemeyer/givaro_fflasffpack_linbox' of git://trac.sagemath.org/sage into t/17635/givaro_fflasffpack_linbox
|
3389f1f | remove obsolete --disable-optimization
|
ce91fb5 | Update to fflas-ffpack-2.2.1rc0 and linbox-1.4.1rc0.
|
comment:94 Changed 6 years ago by
- Description modified (diff)
comment:95 Changed 6 years ago by
- Commit changed from ce91fb5c4af3d46c7d8cdeddfcfc7c2a8b31e69f to 7823566105b8deba838cddf2ead7f174037caa39
comment:96 Changed 6 years ago by
- Description modified (diff)
comment:97 Changed 6 years ago by
I updated linbox and fflas-ffpack release candidates to address the several issues on dynamic lib linkage (including francois PR). I took this opportunity to create a linbox.pc file and update the module_list.py accordingly.
all libraries compile and pass their test suites on my side, and sage builds and passes the test suite with these new rc1's. I also tested the libs but not sage compilation on sardonis (power8).
comment:98 Changed 6 years ago by
OK, so I have done my inspection:
1) list of linbox dependency that we want to be there: ntl, fplll, flint, mpfr, iml. Those are direct build dependencies
readelf -d liblinbox.so.0.0.0 Dynamic section at offset 0x44a80 contains 42 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libfflas.so.1] 0x0000000000000001 (NEEDED) Shared library: [libffpack.so.1] 0x0000000000000001 (NEEDED) Shared library: [libreflapack.so.3] 0x0000000000000001 (NEEDED) Shared library: [libopenblas_threads.so.0] 0x0000000000000001 (NEEDED) Shared library: [libgivaro.so.8] 0x0000000000000001 (NEEDED) Shared library: [libgmpxx.so.4] 0x0000000000000001 (NEEDED) Shared library: [libgmp.so.10] 0x0000000000000001 (NEEDED) Shared library: [libntl-9.7.0.so] 0x0000000000000001 (NEEDED) Shared library: [libfplll.so.0] 0x0000000000000001 (NEEDED) Shared library: [libflint.so.13] 0x0000000000000001 (NEEDED) Shared library: [libmpfr.so.4] 0x0000000000000001 (NEEDED) Shared library: [libiml.so.0] 0x0000000000000001 (NEEDED) Shared library: [libOpenCL.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x000000000000000e (SONAME) Library soname: [liblinbox.so.0]
flint is not in the current list. m4ri and m4rie can be removed as they are looked for by configure
but not used.
2) we want to have opencl (
--without-ocl
) to be turned off, at least for binary build. 3) becausesage/libs/linbox/linbox.pyx
has been given a block# distutils: extra_compile_args = LINBOX_CFLAGS # distutils: libraries = LINBOX_LIBRARIES # distutils: library_dirs = LINBOX_LIBDIR
the entry in modules_list.py
doesn't need libraries = linbox_libs
. cblas_include_dirs
can stay as its content is somehow not included in fflas-ffpack.pc
(but it is in fflas-ffpack-config --cflags
). Similarly fflas-ffpack.pc
has no information on the blas/lapack libraries - may be it should - you would inherit the correct stuff without having to add anything. Someone check this on a vanilla install please.
4) Do we want lapack support in
fflas-ffpack
? That would mean changingLINBOX_BLAS="$(pkg-config --libs cblas)"
toLINBOX_BLAS="$(pkg-config --libs lapack cblas)"
this has an impact on the previous item as you really need to know which libraries are used (especially if your linker is dumb). Note: you may want at leastLINBOX_BLAS="$(pkg-config --cflags --libs cblas)"
in case the headers are in a funny location.
comment:99 Changed 6 years ago by
@ Clement for future releases of fflas-ffpack
and linbox
. Now that you have committed to provide .pc
files, you could insist on pkg-config
being a building requirement. Once you do that, macros like FF_CHECK_GIVARO
and LB_CHECK_FFLAS_FFPACK
can die in peace and be replaced by
PKG_PROG_PKG_CONFIG PKG_CHECK_MODULES(...)
leveraging pkg.m4
which is installed as part of http://pkgconfig.freedesktop.org's pkg-config
. I can probably send you some PR for that in time.
comment:100 Changed 6 years ago by
- Branch changed from u/cpernet/givaro_fflasffpack_linbox to u/fbissey/givaro_fflasffpack_linbox
- Commit changed from 7823566105b8deba838cddf2ead7f174037caa39 to 8cd62e2c23a99466c9d22034d6a0d2db267ea771
Acted upon my comment in (1) and (2). Added some stuff in fflas_ffpack
's spkg-install
to address my final note in section (4). I would rather have the rest of my comments be checked/discussed before they are acted upon.
New commits:
942002d | Merge branch 'develop' into givaro_fflasffpack_linbox
|
8cd62e2 | Addressing issues in in my comments section (1), (2) and final note section (4)
|
comment:101 follow-ups: ↓ 103 ↓ 107 Changed 6 years ago by
Is it just me or the givaro
checksum is wrong?
comment:102 follow-up: ↓ 104 Changed 6 years ago by
Somewhat tangential to this ticket, can someone explain to me why m4rie
depends on givaro
? I cannot find any reference to givaro
in it, but because it is marked as depending on givaro
it got rebuilt when I used make
.
Of course if the dependency is bogus it shouldn't.
comment:103 in reply to: ↑ 101 Changed 6 years ago by
comment:104 in reply to: ↑ 102 Changed 6 years ago by
Replying to fbissey:
Somewhat tangential to this ticket, can someone explain to me why
m4rie
depends ongivaro
? I cannot find any reference togivaro
in it, but because it is marked as depending ongivaro
it got rebuilt when I usedmake
.Of course if the dependency is bogus it shouldn't.
It seems bogus to me. There is no reason for m4rie to depend on givaro and a grep confirms there is no mention of givaro in m4rie. The dependency can be removed.
comment:105 Changed 6 years ago by
I'm fine with your patch on (1) and (2).
(4) Regarding the use of BLAS CFLAGS. The headers of a BLAS are standard both in C and Fortran. Hence fflas-ffpack has the headers for both C and Fortran BLAS (at least for the part of it that it uses). Hence, I did not feel the need to deal with include dirs (also in the .pc file). But ok, there is no harm in adding it and it'll probably prevent some future issues.
(3) Ok to remove these entries in module_list.py. Thanks for pointing out that fflas-ffpack.pc does not mention the BLAS flags. I'll fix this.
comment:106 Changed 6 years ago by
Yes the API to cblas is "standard" that doesn't mean that the headers cannot be slightly different between implementations. You can indeed choose to include your own standard headers but if you include "system headers" for cblas you need to be more careful.
comment:107 in reply to: ↑ 101 Changed 6 years ago by
Replying to fbissey:
Is it just me or the
givaro
checksum is wrong?
I remember it being wrong before too.
@cpernet: are you using a different version from the officially released one or are you changing released tarballs?
comment:108 follow-up: ↓ 109 Changed 6 years ago by
The givaro tarball is missing ./configure
. It looks like autogen.sh
was not run...
comment:109 in reply to: ↑ 108 Changed 6 years ago by
Replying to jdemeyer:
The givaro tarball is missing
./configure
. It looks likeautogen.sh
was not run...
Indeed, I just realized that Github release tool (simply based on a tag) does not work nicely with autotools and make dist targets generating the configure file. I added the proper tar.gz generated by make dist as a binary and will fix the link on this ticket.
comment:110 Changed 6 years ago by
- Description modified (diff)
Requires to update: