On 2016-04-28 15:09, Samuel Thibault wrote: > Control: reassign -1 libc6-dev > Control: tags -1 + experimental > > Graham Inggs, on Wed 27 Apr 2016 15:07:52 +0200, wrote: > > Eztrace-contrib FTBFS with glibc 2.23 available in Experimental and > > Ubuntu Xenial. > > > > > /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const > > > void*, size_t)’: > > > /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this > > > scope > > > return (char *) memcpy (__dest, __src, __n) + __n; > > > ^ > > > /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const > > > void*, size_t)’: > > > /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this > > > scope > > > return (char *) memcpy (__dest, __src, __n) + __n; > > > ^ > > > /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const > > > void*, size_t)’: > > > /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this > > > scope > > > return (char *) memcpy (__dest, __src, __n) + __n; > > > > I found a similar issue had been reported for TensorFlow [1], and the > > solution: > > > > > @e14159 can you try with -D_FORCE_INLINES? I just had the same issue with > > > pcl, > > > I checked the string.h header, and using that preprocessor directive > > > skips the block > > > where the memcpy error appears. There's probably a cleaner workaround > > > though... > > Well, a workaround remains a workaround. There is no reason why we > shouldn't just fix the bug at its source, glibc. Otherwise we'd keep > chasing packages which would need a workaround, that's really not the > way to go. > > So I'm reassigning to glibc.
I am not fully sure the bug is actually in on the libc sid. It looks like that nvcc redefines part of this header in a way that is not compatible with the new version of the header. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net