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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32195 invoked from network); 11 Dec 2022 11:07:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Dec 2022 11:07:41 -0000 Received: (qmail 30298 invoked by uid 550); 11 Dec 2022 11:07:37 -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 30260 invoked from network); 11 Dec 2022 11:07:36 -0000 Date: Sun, 11 Dec 2022 12:07:23 +0100 From: Szabolcs Nagy To: Rich Felker Cc: Yuriy Chernyshov , musl@lists.openwall.com Message-ID: <20221211110723.GI98588@port70.net> Mail-Followup-To: Rich Felker , Yuriy Chernyshov , musl@lists.openwall.com References: <20221211055335.GX29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221211055335.GX29905@brightrain.aerifal.cx> Subject: Re: [musl] Various conflicts with linux system headers (ioctl.h) * 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) > > 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)