From: Yuriy Chernyshov <firstname.lastname@example.org>
To: Rich Felker <email@example.com>,
Yuriy Chernyshov <firstname.lastname@example.org>,
Subject: Re: [musl] Various conflicts with linux system headers (ioctl.h)
Date: Sun, 11 Dec 2022 13:26:38 +0100 [thread overview]
Message-ID: <CAPHLbgNw=-5QPOyRd=nwrCQkLOPmc8py3E2DCEN87-bwOwtOCQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
On Sun, 11 Dec 2022 at 12:07, Szabolcs Nagy <email@example.com> wrote:
> * Rich Felker <firstname.lastname@example.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
> > > > +++ arch/generic/bits/ioctl.h
> > > > @@ -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
> > > 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
Is it possible to add this define into musl codebase?
[-- Attachment #2: Type: text/html, Size: 2572 bytes --]
next prev parent reply other threads:[~2022-12-11 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 10:36 Yuriy Chernyshov
2022-12-11 5:53 ` Rich Felker
2022-12-11 11:07 ` Szabolcs Nagy
2022-12-11 12:26 ` Yuriy Chernyshov [this message]
2022-12-11 12:13 ` Yuriy Chernyshov
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).