Thanks for testing that Josh. Before cleaning up this patch set, I have a few questions. I'm still not clear on how to handle the "std::tr1::shared_ptr < ObjListCtx > ctx;" in librados.hpp. If we change this to ceph::shared_ptr, then we'll also need to some how ship with the translations here: https://github.com/ceph/ceph/blob/port/libc%2B%2B/src/include/memory.h It's also not clear that ceph::shared_ptr should be exposed publically if there is a thought we might start switching out implementations of ceph::shared_ptr via memory.h (e.g. by using boost implementation). On Mon, Dec 30, 2013 at 5:19 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > On 12/27/2013 03:34 PM, Noah Watkins wrote: >> >> On Wed, Oct 30, 2013 at 2:02 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> >> wrote: >>> >>> On 10/29/2013 03:51 PM, Noah Watkins wrote: >>> >>> unsafe to me. Could you check whether you can run 'rados ls' compiled >>> against an old librados, but dynamically loading librados from this >>> branch compiled in c++98 mode? >> >> >> I'm still working on this, but my understanding so far from libc++ >> documentation is that libc++ and libstdc++ are API but not ABI >> compatible, so there shouldn't be an expectation that librados binary >> library built against libstc++ will work if dynamically linked against >> libc++. > > > I meant if it was compiled against libstdc++ both times, I was curious > whether changing std::tr1::shared_ptr to ceph::shared_ptr would result > in any incompatibility. > > I just tried this, and it worked fine (I think because it does not > actually create a new c++ type, but acts like a typedef and just > creates an alias), so I've got no issues with this approach. > > Josh -- 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
