Bacula 9.2.1 fails on 10.4:

[Willem Jan Withagen]

On 29/08/2018 19:59, Dan Langille wrote:
>> On Aug 29, 2018, at 10:59 AM, Jason E. Hale <jhale at freebsd.org> wrote:
>>
>> On Mon, Aug 27, 2018 at 7:42 PM Dan Langille <dan at langille.org> wrote:
>>>
>>>> On Aug 27, 2018, at 7:26 PM, Yuri Pankov <yuripv at yuripv.net> wrote:
>>>>
>>>> Dan Langille wrote:
>>>>> Why would Bacula 9.2.1 compile on 11.2 but fail on 10.4?
>>>>> The error is:
>>>>> bsock.c:439:20: error: use of undeclared identifier 'ENODATA'
>>>>> The complete build logs are at the following URLs. Can you see the cause.
>>>>> 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
>>>>> It doesn't make any sense to me.  Thanks.
>>>>
>>>> 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).
>>>
>>> What is a decent solution? Patch upstream? Patch the port?

I have submitted a very crude patch about 2-3 years ago, to just add it 
to /usr/include/sys/errno.h as alias for ENOATTR.

ENODATA in this file actually defines it as 9919
Which makes interoperability hard, since the call that uses it as 
err-value actually returns ENOATTR.
So for linux compatibility you'd need to match is with ENOATTR(87).

Now linux defines it to be 67, as return err-value of getattr. :(
So if you are going to push raw error values over the line, you will 
need to translate them. (and you'll find that error value sets are 2 
worlds appart)

This is what I have in the Ceph code to have it actually make sense.
ENODATA or ENOATTR is actually defined to be returned with getattr() calls.

/* Make sure that ENODATA is defined in the correct way */
#ifdef ENODATA
#if (ENODATA == 9919)
// #warning ENODATA already defined to be 9919, redefining to fix
// Silencing this warning because it fires at all files where compat.h
// is included after boost files.
//
// This value stems from the definition in the boost library
// And when this case occurs it is due to the fact that boost files
// are included before this file. Redefinition might not help in this
// case since already parsed code has evaluated to the wrong value.
// This would warrant for a definition that would actually be evaluated
// at the location of usage and report a possible conflict.
// This is left up to a future improvement
#elif (ENODATA != 87)
#warning ENODATA already defined to a value different from 87 (ENOATRR), 
refining to fix
#endif
#undef ENODATA
#endif
#define ENODATA ENOATTR


--WjW