On 20-10-2016 18:53, Gregory Farnum wrote: > On Thu, Oct 20, 2016 at 3:21 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote: >> On 20-10-2016 02:49, Willem Jan Withagen wrote: >>> On 20-10-2016 02:21, Willem Jan Withagen wrote: >>>> On 19-10-2016 20:58, kefu chai wrote: >>>>> should have been fixed in master. >>>> >>>> Ehh, >>>> >>>> Not really. >>>> Just tested by running >>>> cd Ceph/master/ceph >>>> git pull >>>> ./do_freebsd.sh >>>> >>>> And I still get the same error. >>>> >>>> Guess I'll have to start bisecting to see where it went wrong. >>> >>> This is the actual commit going wrong >>> >>> commit c9c5235ef7d563b92f44dab63a8ac2b694e69d4f >>> Author: Sage Weil <sage@xxxxxxxxxx> >>> Date: Wed Sep 14 13:32:20 2016 -0400 >>> >>> include/object: conditional denc_traits for snapid_t >>> >>> Signed-off-by: Sage Weil <sage@xxxxxxxxxx> >> >> This all was in pull #11027 >> Last commit that works is: dec0f05288dc4fce0f5ae2de7cf4dd8f9281fe1f >> >> That code is changing all kind of templates... And to be honest, I not >> very comfortable with that. >> >> But obviously GCC seems to able to promote type >> 'const vector<snapid_t>' >> in such a way that it can find a matching function, where as Clang is >> being more selective (as usual) > > That's odd; isn't snapid_t a typedef for uint64_t? > There are a few things like that which are wrapped structs with > implicit conversions, in which case maybe it needs to be defined more > clearly for Clang in this case, or just give it an explicit template > wrapper pointing at le64 (or whichever one it's supposed to be). The other value I see being used in dencode is indeed ceph_le64. Although I understand what you are saying. It is not something that I can just pull out of my hat, since templates still are a large learning field for me. So a hint would be appreciated. --WjW -- 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
