It means that potentially we lose the ability to use an optimized
xdr_* on a platform where we are nominally able to use it; we could
wrap afs_xdr_* around xdr_* on those platforms as a dodge on this if
we care.

This discussion reminds me of something I noticed but have not verified wrt. the devel branch. During some local work on 1.4.x, I was compelled to use xdr_mem (this is an alternative xdr package, not a data type). It was pretty funny actually - I was a while debugging until I noticed that OpenAFS's xdr_mem isn't linked at all, anywhere. Instead, I ended up calling glibc, which (on RHEL5) didn't work at all.

I saw to linking OpenAFS's xdr_mem to libafsrpc, which helped. In the end, I made do without it, though.

Just a pitfall I wanted to share before forgetting all about it.

Cheers
- Felix
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to