Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library

[Ghislain Vaillant <ghisvail@gmail.com>]

2015-06-17 10:41 GMT+01:00 PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr>:

2015-06-17 10:25 GMT+01:00 PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr<mailto:frederic-emmanuel.picca@synchrotron-soleil.fr>>:
Hello Ghislain,

It seems to me thaht I already saw this problem with Jerome... I built my package on a 32bit system.

> cd /«PKGBUILDDIR»/obj-i586-linux-gnu/library && /usr/bin/c++   -DCLFFT_EXPORTS -DclFFT_EXPORTS -m64 -pthread -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -fPIC -I/«PKGBUILDDIR»/obj-i586-linux-gnu/include -I/«PKGBUILDDIR»> /src/library/../include    -o CMakeFiles/clFFT.dir/transform.cpp.o -c /«PKGBUILDDIR»/src/library/transform.cpp

the problem is this -m64 option.


> Is there more to do about it on my end ?

I think that the upstream build system should be fixed and not add the -m64 flag at all.

Maybe you should discuss with the upstream and ask why they add this flag ?

I checked it out and both clBLAS and clFFT actually suffer from the same problem. It seems upstream is rolling its own
"multiarch" detection / selection mechanism. The detection is based on the result of CMAKE_SIZEOF_VOID_P, and the
selection can be overriden via a cmake option.

One option would be to just patch the build system and comment out the part where the offending build flag is set. I
doubt however that upstream would be happy with this solution, since they must have setup their CI infrastructure
around this option I presume.

I am wondering what would be a good solution to suggest upstream about. I guess it is just more convenient for them to

let the build system handle mutliarch builds, including setting the appropriate build flags and arch-dependent install paths
instead of setting a proper build environment up like dh does.

Thoughts ?

Ghis