>On Wed, Apr 04, 2018 at 10:59:18AM +1000, matthew green wrote: >> Christos Zoulas writes: >> > In article <21473.1522789...@splode.eterna.com.au>, >> > matthew green <m...@eterna.com.au> wrote: >> > >"Ryo Shimizu" writes: >> > >> Module Name: xsrc >> > >> Committed By: ryo >> > >> Date: Tue Apr 3 19:53:57 UTC 2018 >> > >> >> > >> Modified Files: >> > >> >> > >> xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting: >> > >> driver.h present.c vblank.c >> > >> >> > >> Log Message: >> > >> Fix compile error on evbarm-aarch64. (incompatible pointer types >> > >initializing 'present_get_ust_msc_ptr') >> > > >> > >sounds like this is a different error. why isn't CARD64 a >> > >uint64_t or similarly compatible for arm64? this sounds >> > >like a problem with the environemnt, and not something to >> > >work around here. >> > > >> > >is _XSERVER64 not defined, or whatever it is? >> > > >> > >thanks. >> > >> > Yes, the problem is the compiler but this is an X bug. >> > >> > uint64_t is defined to be unsigned long long and CARD64 is unsigned long. >> > They are simply not exchangeable and the compiler has the right to define >> > things this way. Well, I've complained to joerg to normalize it and make >> > it like all other _LP64 platforms, but there is an embargo committing to >> > llvm. >> >> can we have a hack in the Makefile for arm64 and not >> touch the sources (for everyone)? > >We can just make the warning non-fatal for now. Like the attached patch. > >Joerg
Sorry for the late reply. I got it. I'll revert and apply Joerg's patch. thanks. BTW, I have a question. uint64 is defined as unsigned long long on NetBSD/aarch64. but on other OS (Linux,FreeBSD), it seems that uint64 is defined as unsigned long. (grep 'AARCH64.*INT64_TYPE' /usr/src/external/bsd/llvm/dist/clang/test/Preprocessor/init.c) Linux long FreeBSD long NetBSD long long OpenBSD long long DARWIN long long Which type should be better? -- ryo shimizu
