Created attachment 627938 [details] build.log Building the GPU target for cholmod fails with the message `nvcc fatal: Unknown option '-fPIC''. AFAIK, nvcc wants the '-fPIC' option with either '--compiler-options' or '-Xcompiler' prepended.
Thank you for the report. We need to have all information at hand before ticket assignment. That is why I ask you to * attach the logs and * paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket
Created attachment 628474 [details] emerge --info Added output of `emerge --info` as well. I've already attached the build.log when creating the ticket. Please tell, if something went wrong there.
It looks like this is a libtool problem. In theory, the build system should prepend the `lt_prog_compiler_pic` with `-Xcompiler` for the nvcc compiler. But I'm not really sure, why this rule is not applied.
Could generate a new log (3.0.13 or 3.0.14) at -j1. Just to make things clearer. I think you have identified the most likely cause of trouble in any case.
(In reply to François Bissey from comment #4) > Could generate a new log (3.0.13 or 3.0.14) at -j1. Just to make things > clearer. I think you have identified the most likely cause of trouble in any > case. No need for that now that I have looked more closely. Trying to identify what is going wrong in libtool.
Can you attach the generated libtool file?
Created attachment 663847 [details] libtool file from 3.0.14
Thanks. That libtool doesn't contain any bits for nvcc, which explains why things fail. Either there is something to fix in configure.ac/Makefile.am to get the bits included or I use an alternative approach.
I have ideas to test. I can put some ebuild in the sage-on-gentoo overlay or attach some files here for you to try. Which works better for you?
(In reply to François Bissey from comment #9) > I have ideas to test. I can put some ebuild in the sage-on-gentoo overlay or > attach some files here for you to try. Which works better for you? you can attach it here, thank you :-)
Sorry for the silence I am completely overloaded left and right.
Created attachment 700836 [details] cholmod_gpu.h Bump. I've tried and failed to debug this. Note also that the current tar.bz2 file for 3.0.14 doesn't include the headers for GPU. cholmod-3.0.14/Include/cholmod_gpu.h I'm attaching it here. I also tried sage-on-gentoo overlay (3.0.13-r3) and no luck.
(In reply to Peter Gustafson from comment #12) > Created attachment 700836 [details] > cholmod_gpu.h > > Bump. I've tried and failed to debug this. > > Note also that the current tar.bz2 file for 3.0.14 doesn't include the > headers for GPU. > > cholmod-3.0.14/Include/cholmod_gpu.h > > I'm attaching it here. > > I also tried sage-on-gentoo overlay (3.0.13-r3) and no luck. Yes, I am sorry. I am completely overwhelmed with various things and that one has taken the back seat. I know precisely why this is failing. Fixing it is another story, I have some leads from a few other packages though. But at the end of the day, it looks like doing C+nvcc is easier with cmake than autoconf.
Any news or further actions or possible fixes/workarounds on this issue?
Note that this failure is caused by USE="cuda". It builds fine without it.
Created attachment 749631 [details, diff] cholmod-3.0.14-fix-CUDA.patch A proposed patch: it's a bit hacky, but it should do the trick. Also I'd suggest to inherit cuda.eclass to avoid problems with some other cuda-related stuff.
Worked for me!
(In reply to Fat-Zer from comment #16) > Created attachment 749631 [details, diff] [details, diff] > cholmod-3.0.14-fix-CUDA.patch > > A proposed patch: it's a bit hacky, but it should do the trick. > > Also I'd suggest to inherit cuda.eclass to avoid problems with some other > cuda-related stuff. Works for me! thx for your patch!
This should probably be upstreamed: https://github.com/DrTimothyAldenDavis/SuiteSparse/issues I see they have plenty of cuda bugs and commits in their repo and, then, this is likely to break again soon I also wonder if maybe we should move everything to a sci-libs/suitesparse ebuild to follow more easily upstream bumps and use their tarballs :/
(In reply to Pacho Ramos from comment #19) > This should probably be upstreamed: > https://github.com/DrTimothyAldenDavis/SuiteSparse/issues > > I see they have plenty of cuda bugs and commits in their repo and, then, > this is likely to break again soon > > I also wonder if maybe we should move everything to a sci-libs/suitesparse > ebuild to follow more easily upstream bumps and use their tarballs :/ That would make some things easier and some things more complicated. There wouldn't really be a configuration phase. Who wants to deal with a superbuild which is directed by a big Makefile? I did some very hackish monolithic build in sagemath and that's not pretty. That being said, getting more stuff upstream would be a great thing.
(In reply to Pacho Ramos from comment #19) > This should probably be upstreamed: > https://github.com/DrTimothyAldenDavis/SuiteSparse/issues > That's a build-system-related issue, they don't use autotools upstream. It looks like a purely gentoo thing, so IMHO there is no reason to bother upstream with that. I suppose, the patch should be applied to what-ever repository where gentoo tarballs are maintained, but I got no idea where it is.
same issue with sci-libs/cholmod-3.0.14
