On 2017-Nov-4, at 10:02 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Nov-4, at 4:58 AM, Ed Maste <emaste at freebsd.org> wrote:
>> On 4 November 2017 at 07:41, Andriy Gapon <avg at freebsd.org> wrote:
>>> On 04/11/2017 12:32, Mark Millard wrote:
>>>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>>>>   if (Err != EOPNOTSUPP)
>>>>     return std::error_code(Err, std::generic_category());
>>>> }
>>> The commit message that you didn't include into your reply contains some 
>>> useful
>>> information that authors / maintainers of this code should probably take 
>>> into
>>> account:
>>>> Please note that EINVAL is used to report that the underlying file system
>>>> does not support the operation (POSIX.1-2008).
>>> Here is a link for that:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
>> I have no idea how they decided EINVAL was a reasonable errno for this case.
>> Mark, can you give this patch a try:
>> diff --git a/contrib/llvm/lib/Support/Unix/Path.inc
>> b/contrib/llvm/lib/Support/Unix/Path.inc
>> index 45097eb918b7..67edb46f0025 100644
>> --- a/contrib/llvm/lib/Support/Unix/Path.inc
>> +++ b/contrib/llvm/lib/Support/Unix/Path.inc
>> @@ -427,7 +427,7 @@ std::error_code resize_file(int FD, uint64_t Size) {
>>  // If we have posix_fallocate use it. Unlike ftruncate it always allocates
>>  // space, so we get an error if the disk is full.
>>  if (int Err = ::posix_fallocate(FD, 0, Size)) {
>> -    if (Err != EOPNOTSUPP)
>> +    if (Err != EINVAL && Err != EOPNOTSUPP)
>>      return std::error_code(Err, std::generic_category());
> I've got a simple buildworld going but I expect that
> it will end up using lld in a form that runs into
> the problem. But I may luck out since I can link a
> trivial main to produce an a.out for amd64.

Actually I take that back: I no longer have
WITH_LLD_IS_LD= as part of my normal amd64
environment. (I did for a time.)

So I will not get the problem.

> It may be appropriate to have notes somewhere about
> what to do for folks that land in the range -r325320
> to whatever revision the updated
> contrib/llvm/lib/Support/Unix/Path.inc ends up at
> and that also have a zfs filesystem context involved.

Explicitly adding to that context-requirement for
having the problem for amd64: and that one has
WITH_LLD_IS_LD= in use.

Of course, for arm64.aarch64 WITH_LLD_IS_LD= is the
normal case and so would be more likely to catch
folks. So this too should be explicit.

> I'll let you know if the build completes vs. not. It
> takes a while since llvm materials are rebuilding.

It should complete since binutils's ld is in use:
I'm not building on aarch64 and reverted to normal
for amd64 some time ago relateive to WITH_LLD_IS_LD= .

Mark Millard
markmi at dsl-only.net

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to