Re: Build 0.6 version fail on musl libc

[Jens Axboe <axboe@kernel.dk>]

On 4/30/20 8:38 AM, Milan P. Stanić wrote:
> On Wed, 2020-04-29 at 14:43, Jens Axboe wrote:
>> On 4/29/20 2:38 PM, Milan P. Stanić wrote:
>>> On Wed, 2020-04-29 at 14:08, Jens Axboe wrote:
>>>> On 4/29/20 2:01 PM, Milan P. Stanić wrote:
>>>>> On Wed, 2020-04-29 at 13:38, Jens Axboe wrote:
>>>>>> On 4/29/20 1:33 PM, Milan P. Stanić wrote:
>>>>>>> On Wed, 2020-04-29 at 10:14, Jens Axboe wrote:
>>>>>>>> On 4/29/20 9:29 AM, Jens Axboe wrote:
>>>>>>>>> On 4/29/20 9:26 AM, Christoph Hellwig wrote:
>>>>>>>>>> On Wed, Apr 29, 2020 at 09:24:40AM -0600, Jens Axboe wrote:
>>>>>>>>>>>
>>>>>>>>>>> Not sure what the best fix is there, for 32-bit, your change will truncate
>>>>>>>>>>> the offset to 32-bit as off_t is only 4 bytes there. At least that's the
>>>>>>>>>>> case for me, maybe musl is different if it just has a nasty define for
>>>>>>>>>>> them.
>>>>>>>>>>>
>>>>>>>>>>> Maybe best to just make them uint64_t or something like that.
>>>>>>>>>>
>>>>>>>>>> The proper LFS type would be off64_t.
>>>>>>>>>
>>>>>>>>> Is it available anywhere? Because I don't have it.
>>>>>>>>
>>>>>>>> There seems to be better luck with __off64_t, but I don't even know
>>>>>>>> how widespread that is... Going to give it a go, we'll see.
>>>>>>>
>>>>>>> AFAIK, __off64_t is glibc specific, defined in /usr/include/fcntl.h:
>>>>>>> ------
>>>>>>> # ifndef __USE_FILE_OFFSET64
>>>>>>> typedef __off_t off_t;
>>>>>>> # else
>>>>>>> typedef __off64_t off_t;
>>>>>>> # endif
>>>>>>> ------
>>>>>>>
>>>>>>> So, this will not work on musl based Linux system, git commit id
>>>>>>> b5096098c62adb19dbf4a39b480909766c9026e7 should be reverted. But you
>>>>>>> know better what to do.
>>>>>>>
>>>>>>> I come with another quick and dirty patch attached to this mail but
>>>>>>> again  I think it is not proper solution, just playing to find (maybe)
>>>>>>> 'good enough' workaround.
>>>>>>
>>>>>> Let's just use uint64_t.
>>>>>
>>>>> This works. Thanks.
>>>>>
>>>>> Next issue is this:
>>>>> ----
>>>>> make[1]: Entering directory '/work/devel/liburing/src'
>>>>>      CC setup.ol
>>>>>      CC queue.ol
>>>>>      CC syscall.ol
>>>>> In file included from syscall.c:9:
>>>>> include/liburing/compat.h:6:2: error: unknown type name 'int64_t'
>>>>>     6 |  int64_t  tv_sec;
>>>>>       |  ^~~~~~~
>>>>> make[1]: *** [Makefile:43: syscall.ol] Error 1
>>>>> make[1]: Leaving directory '/work/devel/liburing/src'
>>>>> make: *** [Makefile:12: all] Error 2
>>>>> ----
>>>>>
>>>>> I fixed it with this patch:
>>>>> --
>>>>> diff --git a/configure b/configure
>>>>> index 30b0a5a..4b44177 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -301,6 +301,7 @@ EOF
>>>>>  fi
>>>>>  if test "$__kernel_timespec" != "yes"; then
>>>>>  cat >> $compat_h << EOF
>>>>> +#include <stdint.h>
>>>>>  struct __kernel_timespec {
>>>>>   int64_t   tv_sec;
>>>>>   long long tv_nsec;
>>>>> --
>>>>>
>>>>> but not sure will that work on glibc.
>>>>
>>>> That should work fine on glibc. Care to send as an actual
>>>> patch, with commit message and signed-off-by? Then I'll add
>>>> it to liburing.
>>> patch is attached.
>> Great thanks, I added a bit to your commit message. Here it is:
>> https://git.kernel.dk/cgit/liburing/commit/?id=8171778c835b6be517c314cf23dd1f5ae061a117
> 
> Yet another issue, build also fails when make enter test subdir saying
> ../src/include/liburing.h:339:35: error: unknown type name 'mode_t'
> 
> I'm attaching build log as liburing-test.log file and patch file
> liburing-fix-mode_t.diff  where I added
> #include <sys/stat.h> in src/include/liburing.h
> 
> After adding this patch 'make' pass build and test, but fails in
> examples subdir, but this is not big problem.

Thanks, applied!

> Maybe you would consider changes in make to have separate invocation for
> make (just build lib), make test and make examples. Will be easier for
> distribution maintainers.

Sure, I'd be fine with that, as long as 'all' or default still builds
the whole thing.

-- 
Jens Axboe