Description of problem: https://review.gluster.org/c/glusterfs/+/21420 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: https://review.gluster.org/21432 (core: libuuid-devel breakage) posted (#2) for review on release-5 by Kaleb KEITHLEY
COMMIT: https://review.gluster.org/21432 committed in release-5 by "Shyamsundar Ranganathan" <srangana> with a commit message- core: libuuid-devel breakage The #include "uuid.h" left over from using .../contrib/uuid is debatably incorrect now that we use the "system header" file /usr/include/uuid/uuid.h from libuuid-devel. Unfortunately this is complicated by things like FreeBSD having its own /usr/include/uuid.h, and the e2fsprogs-libuuid uuid.h in installed - as most third-party packages in FreeBSD are - in /usr/local as /usr/local/include/uuid/uuid.h With a system header file it should at least be #include <uuid.h>, and even better as #include <uuid/uuid.h>, much like the way <sys/types.h> and <net/if.h> are included. Using #include <uuid/uuid.h> guarantees not getting the /usr/include/uuid.h on FreeBSD, but clang/cc knows to find "system" header files like this in /usr/local/include; with or without the -I/... from uuid.pc. Also using #include "uuid.h" leaves the compiler free to find a uuid.h from any -I option it might be passed. (Fortunately we don't have any at this time.) As we now require libuuid-devel or e2fsprogs-libuuid and configure will exit with an error if the uuid.pc file doesn't exist, the HAVE_LIBUUID (including the #elif FreeBSD) tests in compat-uuid.h are redundant. We are guaranteed to have it, so testing for it is a bit silly IMO. It may also break building third party configure scripts if they omit defining it. (Just how hard do we want to make things for third party developers?) Change-Id: I7317f63c806281a5d27de7d3b2208d86965545e1 updates: bz#1639688 Signed-off-by: Kaleb S. KEITHLEY <kkeithle>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report. glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html [2] https://www.gluster.org/pipermail/gluster-users/