similar to: [PATCH v2] lib: Prefer tirpc for XDR, and rationalise how we search for alternatives.

glibc in Fedora is currently configured with `--enable-obsolete-rpc', so I guess we can see the way the wind is blowing. (1) This changes our configure script to prefer libtirpc if it is available. If libtirpc is _not_ available then: (a) Headers must be located in <rpc/xdr.h>, or the user must supply the right CFLAGS. (b) XDR functions must be located in one of -lportablexdr, -lrpc,

Without this option, configure will fail when there is no display. Signed-off-by: Masami HIRATA <msmhrt at gmail.com> --- configure.ac | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index de8a064..61d6f69 100644 --- a/configure.ac +++ b/configure.ac @@ -593,16 +593,16 @@ working. AC_MSG_FAILURE([$QEMU version must be >=

Signed-off-by: Masami HIRATA <msmhrt at gmail.com> --- generator/generator_xdr.ml | 1 + 1 file changed, 1 insertion(+) diff --git a/generator/generator_xdr.ml b/generator/generator_xdr.ml index 9acea8f..ef9e0f2 100644 --- a/generator/generator_xdr.ml +++ b/generator/generator_xdr.ml @@ -40,6 +40,7 @@ let generate_xdr () = generate_header CStyle LGPLv2plus; (* This has to be

--- perl/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/perl/Makefile.am b/perl/Makefile.am index d34adbe..780024f 100644 --- a/perl/Makefile.am +++ b/perl/Makefile.am @@ -87,7 +87,8 @@ clean-local: rm -f Makefile-pl install-data-hook: - $(MAKE) -f Makefile-pl DESTDIR=$(DESTDIR) install + $(MAKE) -C $(srcdir) -f $(abs_builddir)/Makefile-pl \ +

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a

This commit, which is just code motion, moves the common XDR protocol code (libprotocol) and the common errno handling (liberrnostring) into libraries which are each built once and shared between the library and daemon. --- .gitignore | 20 +++++-------- Makefile.am | 1 + common/errnostring/Makefile.am | 45 +++++++++++++++++++++++++++++

This patch series moves some files and directories around but is only code motion (or supposed to be). A new directory, common/, is created for all of the common code which is currently shared in random ways between parts of the project. And src/ becomes lib/ (the largest change, but mostly mechanical). In full this series makes the following changes: src/libprotocol -> common/protocol

Hello Experts, I'm trying to compiling libvirt 6.0.0 on an CentOS 8 env by following the guide here. (https://libvirt.org/compiling.html#compiling) When running the configure command, i encountered the issue of showing "configure: error: Unable to find <rpc/rpc.h>": How can i let the configure command to realize the non-standard header file location of portablexdr

Previous patch series was posted here: https://www.redhat.com/archives/libguestfs/2017-January/msg00059.html v2 simply extends this patch series to cover the extra directories common/edit, common/progress, common/windows and common/parallel. The only remaining item is to consider whether we should rename mllib to something else, mlcommon was my suggestion. Rich.

Since glibc-2.26 removed the /usr/include/rpc/rpc.h, it caused problem even though probing for libtirpc has taken place and worked properly. The problem is that RPC_CFLAGS (usually `-I/usr/include/tirpc` on Linux) was not used in places where it was needed. So the build failed with messages like the following: In file included from guestfs_protocol.c:6:0: guestfs_protocol.h:9:10: fatal error:

Greets, I have to research performance-issues of a W2003-VM within KVM. Right now it's a qcow2-image-file w/ default settings within libvirt (configured by vmm ...) My question: what caching to use? writeback/writethrough/etc ... what to use for data integrity while not getting ultraslow performance? Found https://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf Is there

I tried to Build LLVM under Syllable, but it was failed on the next moment http://clip2net.com/clip/m0/1246547164-clip-99kb.png any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090702/346df366/attachment.html>

---------- Forwarded message --------- From: K. Kahurani <k.kahurani at gmail.com> Date: Sun, May 31, 2020 at 2:26 PM Subject: Hello To: <eblake at redhat.com> Hello, Hopefully this finds you well. This is not a bug report but more or less an inquiry as based on the information acquired from Jim Fehlig a while back, it is possible you would have some important information regarding

v1 was here: https://www.redhat.com/archives/libguestfs/2018-May/msg00042.html v2: - Split into two patches dealing with the different issues. - git format & attribution. I only tested this on Linux but at least it doesn't break things there. Rich.

Hi, from time to time, there have been requests (or attempts, like the mingw port posted on the list some months ago) to make libguestfs work on OSes different than Linux. Of course this would imply using a fixed appliance, since it is currently heavily dependent on Linux. The attached series provides some easy changes in this direction, resolving some of the easy issues found in porting to

Hello, I have attached a patch that allowed the build to complete successfully on macOS. I haven't tried building the daemon under macOS, but I patched two files there in a similar manner to some of the other files for consistency (just the include order for rpc headers). Thanks, Adam Robinson Virtualization and Cloud Infrastructure Senior Information and Technology Services University of

Author: rmesta Repository: /hg/zfs-crypto/gate Revision: 7413fc53072f4145c1b3ac0e2169234084b4c6ab Log message: 6417056 nfssrv should use doors/xdr as its IPC mech to mountd(1m) (fix unref) Files: create: deleted_files/usr/src/cmd/fs.d/nfs/mountd/svc_local.c delete: usr/src/cmd/fs.d/nfs/mountd/svc_local.c

Hi all, I am writing relatively large data files from some simulation code that runs on a variety of different platforms. I just migrated from my own (broken) file format that was not particularly platform independent to the XDR format. Is it possible to read these XDR files directly into R? Cheers, Randall -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help

Author: rmesta Repository: /hg/zfs-crypto/gate Revision: 4af930f29a665f04c4cf91ef1fbc049fb427a304 Log message: 6417056 nfssrv should use doors/xdr as its IPC mech to mountd(1m) Files: create: deleted_files/usr/src/uts/common/rpcsvc/nfsauth_prot.x create: usr/src/cmd/fs.d/nfs/mountd/nfsauth_xdr.c create: usr/src/uts/common/fs/nfs/nfs_auth_xdr.c create: usr/src/uts/common/nfs/auth.h delete:

Full_Name: Thomas Hoffmann Version: 1.0.0 OS: OS/2 Warp 4.0 FP 11 Submission from: (NULL) (141.30.125.20) I autoconfigured/configured the src'es w/o having XDR (#undef HAVE_RPC_XDR_H). In saveload.c , at the beginning of the file the XDR code is enclosed by matching #ifdefs. But in the NEW_SAVE_FORMAT section, there are no #ifdefs around the XDR code. Does this imply that using the new