It certainly would. For those not in the loop, e2fsprogs-libuuid is problematic on FreeBSD because it shadows a symbol defined in libc. There's a workaround, but boost::uuid would be better. -Alan On Sat, Nov 9, 2013 at 9:41 AM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: > Alan, would this fix the problem on FreeBSD? IIRC llibuuid is a > terrible terrible headache, with the recommended approach, being to > upstream changes to e2fsprogs-libuuid. > > On Fri, Nov 8, 2013 at 10:43 PM, Sage Weil <sage@xxxxxxxxxxx> wrote: >> On Sat, 9 Nov 2013, James Harper wrote: >>> Just out of curiosity (recent thread about windows port) I just had a >>> quick go at compiling librados under mingw (win32 cross compile), and >>> one of the errors that popped up was the lack of libuuid under mingw. >>> Ceph appears to use libuuid, but I notice boost appears to include a >>> uuid class too, and it seems that ceph already uses some of boost (which >>> already builds under mingw). >>> >>> Is there anything special about libuuid that would mean boost's uuid >>> class couldn't replace it? And would it be better to still use ceph's >>> uuid.h as a wrapper around the boost uuid class, or to modify ceph to >>> use the boost uuid class directly? >> >> Nice! Boost uuid looks like it would work just fine. It is probably >> easier and less disruptive to use it from within the existing class in >> include/uuid.h. >> >> sage >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
