From: bluemoon <blaumolch@mailbox.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Compilation error with mesa 21.1.6
Date: Tue, 3 Aug 2021 21:11:48 +0200 [thread overview]
Message-ID: <c533bfa9-65c0-43b0-bcdb-4fd2b05d20e4@mailbox.org> (raw)
In-Reply-To: <CDA24KD3XBTH.1NPQQ4L1UPA6W@mussels>
Am 03.08.21 um 19:35 schrieb Érico Nogueira:
> On Tue Aug 3, 2021 at 4:18 AM -03, bluemoon wrote:
>> Hi,
>>
>> I’m trying to compile mesa 21.1.6 for i686 (Void Linux i686-musl).
>> When
>> Gallium Nine is enabled compilation fails. It works on x86_64 but they
>> branch off on 32-bit systems and use memfd. In that code they use
>>
>> ulimit(__UL_GETOPENMAX)
>
> The ulimit(3) man page documents that a value of 4 doesn't have a macro
> for it but is implemented to return the max number of fds. Apparently it
> isn't up to date with the fact that glibc declares a macro, even if
> prefixed with '__'... musl definitely doesn't implement this extension
> to ulimit(3), though.
>
>>
>> which is not available in musl. However, in glibc __UL_GETOPENMAX is
>> assigned the return value of
>>
>> sysconf(_SC_OPEN_MAX)
>>
>> (cf. sysdeps/posix/ulimit.c) which is defined in musl.
>>
>> So before reporting this issue to the mesa developers, I would like to
>> ask if replacing the former with the latter is ok or if there is a
>> caveat I don’t see.
>
> That is the portable way of obtaining the value; fixing the ulimit call
> to use sysconf directly sounds like the only correct way forward. They
> are using a non-documented internal macro in a function that for some
> reason was stretched out to do more.
>
Thank you for your explanation. I’ll open an issue at Mesa’s GitLab
repository.
For reference, the code in question is here:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/nine/nine_memory_helper.c#L1012
>>
>> Thank you!
>
> PS: might be worth investigating the build configuration, Alpine doesn't
> carry a patch for this part:
> https://git.alpinelinux.org/aports/tree/main/mesa?h=master
>
Alpine disables gallium-nine for all targets (line 147 in the APKBUILD)
so they don’t need to patch.
prev parent reply other threads:[~2021-08-03 19:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-03 7:18 bluemoon
2021-08-03 17:35 ` Érico Nogueira
2021-08-03 19:11 ` bluemoon [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c533bfa9-65c0-43b0-bcdb-4fd2b05d20e4@mailbox.org \
--to=blaumolch@mailbox.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.vuxu.org/mirror/musl/
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).