The Samba-Bugzilla – Bug 5714
NetBSD, ENODATA undefined, at least some releases
Last modified: 2009-08-06 17:10:48 UTC
Some source file of Samba-3.2.1 attempt to use the errno define ENODATA, which does not exist on many (or all?) releases of NetBSD,
Please also see bug report 5123 which appears to refer to the same issue:
I'm trying to build Samba 3.2.1 on NetBSD/vax, version 1.5 or newer and kernel 1.5.2 (custom).
In order to make it compile, I've so far entered the following into
include/libsmbclient.h and lib/errmap_unix.c but there may be more.
#define ENODATA 61
The constant 61 was taken from Linux, and is compatible with System V and IBCS, but clashes with another error definition under NetBSD, so I've now decided to copy the solution of Tim Potter <email@example.com> (see bug report 5123) instead.
ENODATA is only used in current code if ENOATTR is not defined. In that case, ENOATTR is defined to be ENODATA.
Does this problem still exist with the current release (3.3)? If so, is the problem that ENOATTR does not exist in NetBSD?
I'll change the component to Build Environment as this is likely an issue for libreplace.
(In reply to comment #1)
> ENODATA is only used in current code if ENOATTR is not defined. In that case,
> ENOATTR is defined to be ENODATA.
> Does this problem still exist with the current release (3.3)? If so, is the
> problem that ENOATTR does not exist in NetBSD?
First, version 4.0.1 appears to be the latest stable release of NetBSD.
Second, I don't know if the problem still remains in v4.0.1 (or 3.3).
However, if not sooner, it would seem that the issue will be resolved in the upcoming 5.0 release, which will apparently define both ENODATA and ENOATTR to different values, 89 and 93, respectively:
.It Er 89 ENODATA Em "No message available" .
.It Er 93 ENOATTR Em "Attribute not found" .
(Of course, none of that is relevant to older versions, and it is desirable to have Samba compile properly on at least a subset of older releases.)
(Furthermore regarding NetBSD, or at least older releases thereof, see also the bug I reported concerning getaddrinfo() and AI_ADDRCONFIG.)
The ENODATA and ENOATTR defines appear to be issues in at least some releases of FreeBSD as well:
What about OpenBSD?
I wrote (In reply to comment #2):
> (Furthermore regarding NetBSD, or at least older releases thereof, see also the
> bug I reported concerning getaddrinfo() and AI_ADDRCONFIG.)
I did not report it. However, I encountered it, and was going to report it, but then discovered a similar bug (with regard to AIX) so I just added a comment:
Created attachment 4045 [details]
Does this fix work for you ?
Created attachment 4054 [details]
Sample patch to fix undefined ENODATA compile error
(In reply to comment #5)
> Created an attachment (id=4045) [details]
> Proposed patch
> Does this fix work for you ?
I haven't tested it, but the probability that it would work is very high, as it's very similar to the actual modification that I already applied in order to successfully resolve the problem on my system. I'm attaching a "diff -u" of the file on my system against samba-3.2.1, and the patch seems identical to the one suggested in Bug 5123: https://bugzilla.samba.org/show_bug.cgi?id=5123
which is unsurprising, considering that's where I got the tip from.
It seems to me that there is very little difference between the patch I'm posting (for comparison) and the one you proposed, the main difference being your choice of ENOENT rather than EAGAIN. I haven't taken the time to try to understand the message the error code is meant is convey in the context where it may be encountered by Samba, and whether under those circumstances the error condition is better described by "no such [file or directoty] entry" (ENOENT) or "try again - no data, or less data than requested, was vailable)" (EAGAIN). EWOULDBLOCK is another and often numerically equivalent way of reporting that no data is available at the time. EINTR is also often closely related, as is EINPROGRESS. However, caution should be taken not to overgeneralise.
Jeremy, has that patch been pushed and if so, can we close it ?
Pushed into master (for 3.5.x). Please re-open and assign to Karolin if you want to back-port it to 3.4.1.