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

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
>
> --
> Dan Langille - BSDCan / PGCon
> d...@langille.org
>
>
>
>

-- 
Radosław Korzeniewski
rados...@korzeniewski.net
------------------------------------------------------------------------------
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

Reply via email to