Hello Dan,
śr., 29 sie 2018 o 20:35 Dan Langille <d...@langille.org> napisał(a):
> > On Aug 29, 2018, at 2:08 PM, Dan Langille <d...@langille.org> wrote:
> >
> >> On Aug 28, 2018, at 8:51 AM, Radosław Korzeniewski <
> rados...@korzeniewski.net> wrote:
> >>
> >> Hello,
> >>
> >> wt., 28 sie 2018 o 14:42 Dan Langille <d...@langille.org> napisał(a):
> >> The comment in the patch is not accurate: "not defined on BSD systems"
> because this is not always true.
> >>
> >> Sorry about that. I'm not a *BSD expert, I wrote my understanding of
> the problem.
> >>
> >>
> >> 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?
> >>
> >> Well, the fix to this problem is the solution existed in Bacula for a
> very long time. I just placed it in one file (bsockcore.c) but forget to
> add it to other one (bsock.c). I'm not sure who was an original author for
> this fix, I have to check a git log.
> >>
> >> I am still working on finding a better solution.
> >>
> >> Great! Thank you.
> >
> > I got a reply back from the FreeBSD ports mailing list. I do not yet
> see that in the mailing list archives, so I will copy/paste it here.
> >
> > The patch has been uploaded to:
> https://gist.github.com/dlangille/2f59782e4b2ed3bb15922932be8aa0c3
> >
> > Does this suggestion make more sense than:
> http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-9.2&id=eea817f035d32221ab46d1a4f95193cd4d6dbda7
> >
> > Thank you.
> >
> > ###
> >
> > You can patch the port for now and submit it upstream. Looks like they
> > had ENODATA defined as EPIPE and missed it when they refactored:
> >
> http://www.bacula.org/git/cgit.cgi/bacula/commit/bacula/src/lib/bsock.c?h=Release-9.2.1&id=c3c124adbe784a55bb31c66401630b2d22768baf
> .
> > Now that code is in:
> >
> http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/src/lib/bsockcore.c?h=Release-9.2.1#n44
> ,
> > but it needs to be in both files.
> > I think it would make more sense to factor it out to src/baconfig.h.
> > That way, they could remove the #if block from bsockcore.c. I've
> > attached a patch and put it in plain text below in case it gets
> > scrubbed.
>
As I understand it, the patch does not propose the "better fix" but to
place an existing fix in the different place. Right?
best regards
--
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
