On Mar 9, 2012, at 6:25 AM, g....@free.fr wrote:
>> sed -i -e '41s/ENOENT/& || errno == EINVAL/' tests/test-readlink.h
>>
>> OOH, it doesn't appear to be a "huge issue", so the sed is
>> nice...OTOH, it's still a red flag because I don't see this issue
>> when building from my host platform (openSUSE-11.4). That makes me
>> think there's a glibc or kernel patch that we're missing.
>>
> The anwser should be no ( not fixed on kernel side or glibc).
> So adjusting the test is the proper fix.
> That way, the test support all kernels (as newer report EINVAL).
Thanks for all the responses (I'm still looking through some info Pierre sent
me).
@Pierre: I'm talking about *testing* m4 (in Chap 6). If you're using
openSUSE-12.1, you should see this error if you run the tests for m4--I did.
@Gilles: Thanks for the newer-kernels-cause-this theory. It makes sense...
...However, I'm not sure the problem is being seen clearly. The issue is that
the newer kernel/glibc are violating the POSIX spec, but they claim to conform
to it (see below).
I'm not sure how this wasn't seen by folks building 7.0 from 7.0, since I use a
vanilla build (other than kernel config, which is left open-ended). I would
expect this error shows for everyone, unless everyone else dialed in a
different kernel config that fixes it, which seems unlikely (or ignored the
error--more plausible).
The explanation that "newer kernels cause this issue" makes sense (since 7.0 is
newer than my host, and newer hosts I tried, including openSUSE-12.1, have the
same issue when running the check for m4). I understand that the sed massages
the tests so they pass, but the question is whether or not the test is showing
us something that needs investigating.
Q
Long explanation follows...
Someone upstream is doing something they may not intend. Looks like either the
kernel or glibc. readlink(2) is a POSIX function, though it's older than that
(4.2BSD). From 'man 2 readlink' (with the man page installed by LFS):
CONFORMING TO
4.4BSD (readlink() first appeared in 4.2BSD), POSIX.1-2001.
So, if we look at the POSIX reference:
http://pubs.opengroup.org/onlinepubs/009695399/
it says: "The readlink() function shall fail if:
[EINVAL]
The path argument names a file that is not a symbolic link.
...
[ENOENT]
A component of path does not name an existing file or path is an empty
string."
If we look at the test which causes the error:
ASSERT (func ("", buf, sizeof buf) == -1);
ASSERT (errno == ENOENT);
That's clearly a zero-length string being passed to readlink(2), and it should
clearly be returning ENOENT. (Rationale: I think it's more reasonable to
assume that the return value returned should be the one that most resembles the
problem. I think the zero-length string is closest.)
It seems clear the test is "correct", because it adheres to the most reasonable
reading of the relevant spec.
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
