Hi Michael, On Wed, Sep 7, 2016 at 12:36 AM, Michael Prokop <m...@debian.org> wrote: > * László Böszörményi [Wed Aug 26, 2015 at 07:28:02AM +0200]: >> On Fri, Aug 21, 2015 at 10:10 AM, Chris Lamb <la...@debian.org> wrote: >> > From a cursory glance, devmapper.pc specifies Requires.Private librt, >> > which doesn't have a librt.pc (which is likely correct as it's meant to >> > be linked statically? I'll leave it to you). > >> You are right in the sense that without 'Requires.private:' the >> devmapper library is found correctly. On the other hand I don't think >> static linking is mandatory as libdevmapper.so.* exists and is under >> /lib (no need to have /usr mounted, can be used in emergency shells as >> well). Can be a cmake issue? Will investigate further. > > Any news here, László? I'm asking because this is an RC bug and > therefore preventing tcplay to enter Debian/stretch. Last checked by me in May and couldn't make it compile as far as I can remember.
> This issue was also reported towards upstream: > https://github.com/bwalex/tc-play/issues/50 This is a very different one. > I was trying to reproduce it, though couldn't: > > | -- Checking for module 'devmapper' > | -- Found devmapper, version 1.02.133 > > Instead if fails with: [...] > when compiling against current Debian/unstable. It looks like that's > an issue of static vs dynamic library linking. When replacing: > > set (CFLAGS_COMMON "-std=c99 -fPIE ${CFLAGS_LINUX} ${CFLAGS_WARN} > ${CFLAGS_VER}") > > in CMakeLists.txt with (so adding the '-fPIC' option there): > > set (CFLAGS_COMMON "-std=c99 -fPIE -fPIC ${CFLAGS_LINUX} ${CFLAGS_WARN} > ${CFLAGS_VER}") > > it indeed compiles for me. Indeed, this fixes the current issue. > Can you please take care of an according fixed package upload? Sure, it's in its way. Thanks for the heads-up, Laszlo/GCS
