mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Compilation error with mesa 21.1.6
@ 2021-08-03  7:18 bluemoon
  2021-08-03 17:35 ` Érico Nogueira
  0 siblings, 1 reply; 3+ messages in thread
From: bluemoon @ 2021-08-03  7:18 UTC (permalink / raw)
  To: musl

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)

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.

Thank you!



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Compilation error with mesa 21.1.6
  2021-08-03  7:18 [musl] Compilation error with mesa 21.1.6 bluemoon
@ 2021-08-03 17:35 ` Érico Nogueira
  2021-08-03 19:11   ` bluemoon
  0 siblings, 1 reply; 3+ messages in thread
From: Érico Nogueira @ 2021-08-03 17:35 UTC (permalink / raw)
  To: musl

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!

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Compilation error with mesa 21.1.6
  2021-08-03 17:35 ` Érico Nogueira
@ 2021-08-03 19:11   ` bluemoon
  0 siblings, 0 replies; 3+ messages in thread
From: bluemoon @ 2021-08-03 19:11 UTC (permalink / raw)
  To: musl

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-08-03 19:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-03  7:18 [musl] Compilation error with mesa 21.1.6 bluemoon
2021-08-03 17:35 ` Érico Nogueira
2021-08-03 19:11   ` bluemoon

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git