On 29/08/2018 19:59, Dan Langille wrote:
On Aug 29, 2018, at 10:59 AM, Jason E. Hale <jh...@freebsd.org> wrote:
On Mon, Aug 27, 2018 at 7:42 PM Dan Langille <d...@langille.org> wrote:
On Aug 27, 2018, at 7:26 PM, Yuri Pankov <yur...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
