From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30783 invoked from network); 11 Dec 2022 15:17:24 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Dec 2022 15:17:24 -0000 Received: (qmail 32335 invoked by uid 550); 11 Dec 2022 15:17:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25650 invoked from network); 11 Dec 2022 12:27:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=DRpNZEvTkLIhFPPENs891RhU5a0UcqzcWCgW2Ty0c6I=; b=nTsryMbiCfXF+NKGeTSO52JQ1fFCM+ND5d7P8uh2Jrw0MBg/52n6+u0CXY6dgMiBMh 9sr3iQ+ZRCWGH2IoyM1GYCXSXOaPsamlX75zowmBIqkH5gQMxRcPXHZiZP0Ohp5WxoFx KjcEaKYaZ56bURDYZnCjWjpRRo+qsqYGJqkN/hu1eLlORkFbEF2u92yrRH5n6GCszduR V28OASUWwuupAKC+gZSA+EuIkT5Ye+6AbyiibC3q7GoGBGPfbTl5gDdx/wxoahO7spMS ukrwzCZLoPIZDCW3YvB43NXHqy9lQ8Ell2hfjjQ0gzAGksqRPiGwMESKYnnUbLE6FlSa 4BPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DRpNZEvTkLIhFPPENs891RhU5a0UcqzcWCgW2Ty0c6I=; b=3Ce3Ooswja1ahE5aUWQ3MozlCdnoTkfNq+za5cxQ/8xPPYdSNwAe/pnBvIRb/n7XIZ HD8QyWAD7xcZQCxEQpysDvGF+UdAQb7XZe0+Mvcd1TFyJiJo+a3OGrWDgfVw7PT/6t73 8Fz5ICjRI+JbUWaFL95iUUBHDurFIX+mXN8Ovwy38/13mXxfoQwsqp91vFv7WcL1PQFS zkCvs9/zx7Mt32N2a6md9ZYhhCf7Ju1+ZNNEFP5sCwntVjtJTZtCkVKa796qW86TA7Kg SqXKso30rvyvB7xj0JSW2Q0CSKxaKHnELipOEPPuNQ1YkYnTAK6JFbOfiuhP9MaVNmw1 Ed1g== X-Gm-Message-State: ANoB5pkcml+izGQ4yPVPFNGjT80urLi3DbNEmQ4YJFWrKtfC0sKYtido UzbbYQyuYLPSGImNvwLFZxr5JWNQXSW9KkqYWN0= X-Google-Smtp-Source: AA0mqf6rMDTghrqoEm0VyMcU1EcCbUidT7brtZYZeEB4RaIPkwtsuCOuUfBk0h/wJNux9XBF9OlKi2NALWfTPDslBBo= X-Received: by 2002:a05:620a:13f1:b0:6fa:1c1:26de with SMTP id h17-20020a05620a13f100b006fa01c126demr84373402qkl.511.1670761608893; Sun, 11 Dec 2022 04:26:48 -0800 (PST) MIME-Version: 1.0 References: <20221211055335.GX29905@brightrain.aerifal.cx> <20221211110723.GI98588@port70.net> In-Reply-To: <20221211110723.GI98588@port70.net> From: Yuriy Chernyshov Date: Sun, 11 Dec 2022 13:26:38 +0100 Message-ID: To: Rich Felker , Yuriy Chernyshov , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000033d97b05ef8c8004" Subject: Re: [musl] Various conflicts with linux system headers (ioctl.h) --00000000000033d97b05ef8c8004 Content-Type: text/plain; charset="UTF-8" On Sun, 11 Dec 2022 at 12:07, Szabolcs Nagy wrote: > * Rich Felker [2022-12-11 00:53:35 -0500]: > > On Tue, Dec 06, 2022 at 11:36:24AM +0100, Yuriy Chernyshov wrote: > > > The following workaround helps, but looks quite ugly: > > > > > > --- arch/generic/bits/ioctl.h > (b4624b83eafbdd5f2e2c37374d62426c27687f35) > > > > +++ arch/generic/bits/ioctl.h > (d545cbc1ae3f5c9132eb26b176bef3638c9d8063) > > > > @@ -1,3 +1,9 @@ > > > > +#undef _IO > > > > +#undef _IOC > > > > +#undef _IOR > > > > +#undef _IOW > > > > +#undef _IOWR > > > > + > > > > #define _IOC(a,b,c,d) ( ((a)<<30) | ((b)<<8) | (c) | ((d)<<16) ) > > > > #define _IOC_NONE 0U > > > > #define _IOC_WRITE 1U > > > > > > > > > > Is it possible to get official solution for the macro conflict? > > > > It's explicitly unsupported to include linux/* headers that might > > produce conflicting definitions *before* the libc headers they might > > conflict with. Does the same problem happen if you put the linux/* > > headers after? > > i don't think reordering can fix the conflict as linux defines the > macros unconditionally. (and glibc relies on the linux definitions) > Indeed, the reording was the first thing I have tried. I have failed to find a working solution. > > NB: we have to use linux/fs.h in order to get BLKGETSIZE64 constant > defined > > > which is missing in sys/ioctl.h. > > musl defines that in sys/mount.h (just like glibc) > This would have been a solution for BLKGETSIZE64, but once I have started to refactor things, I got more problems. Our code also depends on BLKDISCARD, which is not defined by neither musl nor glibc. Is it possible to add this define into musl codebase? --00000000000033d97b05ef8c8004 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 11 Dec 2022 at 12:07, Szabolcs Nagy <nsz@port70.net> wrote:
* Rich Felker <dalias@libc.org> [2022-12-11 00:53:35 -0500]= :
> On Tue, Dec 06, 2022 at 11:36:24AM +0100, Yuriy Chernyshov wrote:
> > The following workaround helps, but looks quite ugly:
> >
> > --- arch/generic/bits/ioctl.h (b4624b83eafbdd5f2e2c37374d62426c27= 687f35)
> > > +++ arch/generic/bits/ioctl.h (d545cbc1ae3f5c9132eb26b176bef= 3638c9d8063)
> > > @@ -1,3 +1,9 @@
> > > +#undef _IO
> > > +#undef _IOC
> > > +#undef _IOR
> > > +#undef _IOW
> > > +#undef _IOWR
> > > +
> > >=C2=A0 #define _IOC(a,b,c,d) ( ((a)<<30) | ((b)<<= 8) | (c) | ((d)<<16) )
> > >=C2=A0 #define _IOC_NONE=C2=A0 0U
> > >=C2=A0 #define _IOC_WRITE 1U
> > >
> >
> > Is it possible to get official solution for the macro conflict? >
> It's explicitly unsupported to include linux/* headers that might<= br> > produce conflicting definitions *before* the libc headers they might > conflict with. Does the same problem happen if you put the linux/*
> headers after?

i don't think reordering can fix the conflict as linux defines the
macros unconditionally. (and glibc relies on the linux definitions)

Indeed, the reording was the first thing I hav= e tried.
I have failed to find a working solution.

> > NB: we have to use linux/fs.h in order to get BLKGETSIZE64 consta= nt defined
> > which is missing in sys/ioctl.h.

musl defines that in sys/mount.h (just like glibc)
This would have been a solution=20 for BLKGETSIZE64, but once I have started to refactor things, I got more pr= oblems.
Our code also depends on BLKDISCARD, which is not defined= by neither musl nor glibc.
Is it possible to add this define int= o musl codebase?

--00000000000033d97b05ef8c8004--