Created attachment 1455275 [details] fix-xdr-file.patch Description of problem: With some toolchains (latest buildroot for example) the rpcgen rejects to process the rpc/xdr/src/changelog-xdr.x file, because it contains "unsigned long" integer declarations. Looking at the standard, long is not supported in XDR: https://tools.ietf.org/html/rfc4506#section-4.2 Version-Release number of selected component (if applicable): How reproducible: Compile gluster with buildroot 2018.05. Actual results: ------------------------------------ Making all in rpc/xdr/gen unsigned long seq; ^^^^^^^^^^^^^^^^^^^^^^^^ changelog-xdr.x, line 30: expected ';' Makefile:562: recipe for target 'changelog-xdr.h' failed make[5]: *** [changelog-xdr.h] Error 1 ------------------------------------ Expected results: Compilation without error. Additional info: fix attached
Thanks for the patch! In most occasions an 'unsigned long' should be converted to a u_quad_t in the .x file. That matches a uint64_t for the C interface for most common architectures.
(In reply to Niels de Vos from comment #1) > In most occasions an 'unsigned long' should be converted to a u_quad_t in > the .x file. That matches a uint64_t for the C interface for most common > architectures. I did some more research on this. So the XDR specification really only allows "int" (32 bit) and "hyper" (64 bit) declarations in .x files. "unsigned hyper" on my machine is converted to "u_quad_t" in the generated .h file, but that seems to be an internal compatibility type, that is mapped then to the corresponding platform specific type then. Since "int" in XDR is already 32 bit (which is the minimum size of a C long), my understanding is to use only "int" in .x files, if you don't need more than 32 bit. One might think that rpcgen also accepts u_long or u_quad_t in .x files, but that is only true in a way that it accepts everything that it doesn't know about (like foo_bar_t) and just puts it 1:1 into the .h file then. But that I would regard as a hack, because it makes the RPC definition platform dependent, which undermines it's original idea.
BTW, the rpcgen, that doesn't accept "long" is the one from nfs-utils, which is used in buildroot. It doesn't implement "hyper" either, apparently.