On 15 August 2017 at 03:30, Dan Kortschak <dan.kortsc...@adelaide.edu.au> wrote: > Well that's odd. That works for me too (after having changes the > typedef to an import of stddef.h). > > It shouldn't be a uintptr (or even a uint64, it should be an int - for > reasons that are boring and result from the C code-base design).
I changed h5t_VARIABLE from int64 to uintptr and it installs OK for me. Given that it's an unexported variable and only used in one place, I can't quite see why the type is that important. > > The failure that we see is here[1] for this sha[2]. > > [1]https://travis-ci.org/gonum/hdf5/jobs/263000745#L513 > [2]https://github.com/gonum/hdf5/commit/92c9b50e0014636ad797e9aa6072125 > 165c1f75a > > On Mon, 2017-08-14 at 18:24 +0100, roger peppe wrote: >> On 10 August 2017 at 23:21, Dan Kortschak <dan.kortsc...@adelaide.edu >> .au> wrote: >> > Yeah, that doesn't work. Returning the value from the C.func does >> > though. The whole system is pretty queasy-making. >> >> It works for me: >> >> https://play.golang.org/p/I6HSdFHMog >> >> I'd probably use a uintptr as being closer in spirit to size_t, >> though. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
