Date: Mon, 3 Sep 2018 19:51:50 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Dan Langille <dan@langille.org>, "Jason E. Hale" <jhale@freebsd.org> Cc: Yuri Pankov <yuripv@yuripv.net>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: Bacula 9.2.1 fails on 10.4: Message-ID: <59a62b46-73fa-c16d-9663-cf8888265bf0@digiware.nl> In-Reply-To: <5B4F0FB9-0F97-42BF-9692-698F7ED4AE11@langille.org> References: <320B7D85-8E73-4214-8343-DDA3F448E473@langille.org> <4e03e6b7-f866-f6f8-bab1-285fbe36a0f9@yuripv.net> <23601736-1846-4B86-AAC2-1A0871852C21@langille.org> <CAJE75NEU446M4R5sWTiLyhbmZZk%2B9TnTZpoFdwvq3FSCWwpKmQ@mail.gmail.com> <5B4F0FB9-0F97-42BF-9692-698F7ED4AE11@langille.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29/08/2018 19:59, Dan Langille wrote: >> On Aug 29, 2018, at 10:59 AM, Jason E. Hale <jhale@freebsd.org> wrote: >> >> On Mon, Aug 27, 2018 at 7:42 PM Dan Langille <dan@langille.org> wrote: >>> >>>> On Aug 27, 2018, at 7:26 PM, Yuri Pankov <yuripv@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59a62b46-73fa-c16d-9663-cf8888265bf0>