Since we as developers rarely test the case where some library is
statically not available, that side of the code was hardly tested,
except by unfortunate users in the field who often hit cases where
functions were missing or misdeclared. In fact, when making this
change I noticed several bugs like that.
Change it so that this code is autogenerated, and therefore always
correct and up to date.
Previous code which looked like this:
int
optgroup_acl_available (void)
{
return 0;
}
char * __attribute__((noreturn))
do_acl_get_file (const char *path, const char *acltype)
{
abort ();
}
/* etc */
is replaced by a single line:
OPTGROUP_ACL_NOT_AVAILABLE
Since I made lots of changes to the Erlang bindings (prompted by
Coverity), I wasn't confident that something didn't break because
there were no real tests before.
Comment from Coverity:
libguestfs-1.19.66/erlang/erl-guestfs-proto.c:115: sign_extension:
Suspicious implicit sign extension: "buf[0]" with type "unsigned char"
(8 bits, unsigned) is promoted in "(buf[0] << 24) | (buf[1] << 16) |
(buf[2] << 8) | buf[3]" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long" (64 bits, unsigned). If
"(buf[0] << 24) | (buf[1] << 16) | (buf[2] << 8) | buf[3]" is greater
than 0x7FFFFFFF, the upper bits of the result will all be 1.
In the previous code, appliance was unconditionally set to NULL and so
we never added the dummy appliance slot to g->drives. This probably
doesn't matter, since hotplugging doesn't work for the 'appliance'
attach-method. Despite that, it's better to get this right.
This fixes commit ed7fda161e.
For some guestfs_set_* calls, add checks for error, when error might
possibly occur. eg. It's plausible that guestfs_set_network might
fail if the attach-method being used doesn't support it (although this
doesn't happen at the moment).
In other cases, don't check for errors, eg. if the error doesn't
matter or there's nothing we could plausibly do about it.
These configure flags enable code profiling (with gprof) and code
coverage (with gcov) respectively.
Although this is a nice idea, it's not currently very useful.
Libtool mangles filenames in such a way that gcov cannot locate its
datafiles.
Profiling is of dubious utility with libguestfs which is not CPU-bound
and relies extensively on running external programs (oprofile-like
system profiling that took into account libguestfs + qemu or
libguestfs + qemu + the appliance + filesystem tools *would* be
useful).
Also neither flag will help in capturing data from the appliance.
latest archlinux has some small changes:
btrfs-progs-unstable --> btrfs-progs
genisoimage --> cdrkit
iproute --> iproute2
module-init-tools --> kmod
procps --> procps-ng
udev --> systemd
util-linux-ng --> util-linux
and could you plz add the below packages
lrzip
less
sed
RWMJ: I took this opportunity to make some general cleanups to the file:
- add 'less' and 'sed' for everyone
- 'module-init-tools' & 'kmod'[1]
- 'procps' & 'procps-ng'[1]
- 'util-linux' & 'util-linux-ng'[1]
- sort the ArchLinux packages into order
[1] Note that febootstrap is supposed to ignore packages it doesn't
know about.
The way the existing configure script worked, @VG@ would be empty, and
it would run all the way through the check-valgrind rule successfully
without actually running anything under valgrind.
