> On Aug 28, 2018, at 8:22 AM, Radosław Korzeniewski > <rados...@korzeniewski.net> wrote: > > wt., 28 sie 2018 o 00:53 Dan Langille <d...@langille.org> napisał(a): > > On Aug 14, 2018, at 11:16 AM, Martin Simmons <mar...@lispworks.com> wrote: > > > >>>>>> On Tue, 14 Aug 2018 16:34:07 +0200, Radosław Korzeniewski said: > >> > >> Hello Martin, > >> > >> 2018-08-14 12:56 GMT+02:00 Martin Simmons <mar...@lispworks.com>: > >> > >>> Sorry to say that it doesn't compile on FreeBSD (see below). > >>> > >>> The warnings about BSOCK::recv are probably generic and occur in every > >>> file. > >>> > >> > >> A standard Linux compile does not raise any warnings here. > > > > The warning will depend on the C compiler. I'm using the default FreeBSD > > clang-based C compiler and passing -Wall. It looks like gcc (gcc7 at least) > > does not issue this warning unless you explicitly pass -Woverloaded-virtual. > > > > > >>> > >>> There is some hack for ENODATA in bsockcore.c, but not in bsock.c. > >>> > >> > >> Yes, it should be in bsock.c too. > >> > >> Could you check the following patch: > >> > >> diff --git a/bacula/src/lib/bsock.c b/bacula/src/lib/bsock.c > >> index a6e4d98c3..c6bed981d 100644 > >> --- a/bacula/src/lib/bsock.c > >> +++ b/bacula/src/lib/bsock.c > >> @@ -40,6 +40,10 @@ > >> > >> #define BSOCK_DEBUG_LVL 900 > >> > >> +#if !defined(ENODATA) /* not defined on BSD systems */ > >> +#define ENODATA EPIPE > >> +#endif > >> + > >> /* Commands sent to Director */ > >> static char hello[] = "Hello %s calling\n"; > > > > Yes, thanks, that fixes the compilation. > > I didn't know about the above problem when I upgraded the FreeBSD port to > 9.2.1, which compiles fine on FreeBSD 11.2 > > Overnight received a report of a failure on FreeBSD 10.4 > > Tonight, I ran tests on both FreeBSD 11.2 and 10.4 to reproduce the problem. > Indeed, it fails on 10.4 > > I am not sure where to look for ENODATA which is used by Bacula, but I found > it defined on both systems. Details here: > > https://gist.github.com/dlangille/1c91c184618e336b6ec8d231329b2308 > > ### > > root@104amd64-default:~ # grep -r ENODATA /usr/include/ > /usr/include/bsm/audit_errno.h:#define BSM_ERRNO_ENODATA 61 > /* Solaris/Darwin/Linux-specific. */ > /usr/include/c++/v1/cerrno:#ifndef ENODATA > /usr/include/c++/v1/cerrno:#define ENODATA 9919 > /usr/include/c++/v1/system_error: no_message_available, // > ENODATA > /usr/include/c++/v1/system_error:#ifdef ENODATA > /usr/include/c++/v1/system_error: no_message_available = > ENODATA, > /usr/include/c++/v1/tr1/cerrno:#ifndef ENODATA > /usr/include/c++/v1/tr1/cerrno:#define ENODATA 9919 > /usr/include/c++/v1/tr1/system_error: no_message_available, > // ENODATA > /usr/include/c++/v1/tr1/system_error:#ifdef ENODATA > /usr/include/c++/v1/tr1/system_error: no_message_available > = ENODATA, > root@104amd64-default:~ # > ### > > Are any of those what Bacula needs? Could it be that Bacula on 10.4 is not > pulling in the appropriate include files? > > The complete build logs are at the following URLs and I hope they are of use > to debug the issue. > > 11.2: > https://services.unixathome.org/poudriere/data/112amd64-default/2018-08-27_21h15m53s/logs/bacula9-client-9.2.1.log > 10.4: > https://services.unixathome.org/poudriere/data/104amd64-default/2018-08-27_21h43m31s/logs/errors/bacula9-client-9.2.1.log >
> Hello Dan, > > Yes, the Release 9.2.1 has some compilation problem on *BSD. The problem was > fixed and patch (eea817f035d32221ab46d1a4f95193cd4d6dbda7) is available in > git repository. > > best regards > Thank you. The comment in the patch is not accurate: "not defined on BSD systems" because this is not always true. It appears to be a special circumstance as indicated by my initial queries here: https://lists.freebsd.org/pipermail/freebsd-ports/2018-August/114171.html From the above URL: "I'd say it's libc++ missing its errno.h having ENODATA defined if the following is true: - both builds are using clang++ - both builds are using libc++ That header defining ENODATA exists in 11.2 and doesn't exist in 10.4 (contrib/libc++/include/errno.h)." On a FreeBSD 11 box, I get this value: $ grep ENODATA /usr/src/contrib/libc++/include/errno.h #ifndef ENODATA #define ENODATA 9919 Whereas: $ grep EPIPE /usr/include/c++/v1/errno.h #ifndef EPIPE #define EPIPE 9950\ On FreeBSD 10.4, we see: $ grep EPIPE * errno.h:#define EPIPE 32 /* Broken pipe */ I do not know the implications of using a different value here. Can you advise here please? I am still working on finding a better solution. -- Dan Langille - BSDCan / PGCon d...@langille.org ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
