2015-06-17 10:41 GMT+01:00 PICCA Frederic-Emmanuel < [email protected]>:
> > > 2015-06-17 10:25 GMT+01:00 PICCA Frederic-Emmanuel < > [email protected]<mailto: > [email protected]>>: > 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
