Le lun. 27 janv. 2025 à 17:41, Arnd Bergmann <
[email protected]> a écrit :
On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:
Hi,
as discussed in
https://github.com/libuv/libuv/issues/4678
and associated build failures https://buildd.debian.org/status/package.php?p=libuv1&suite=experimental
It seems that gcc is doing something wrong with the offset parameter of preadv, pwritev.
The same problem happens with optimization levels 0, 1, 2.
The call is made at
https://salsa.debian.org/debian/libuv1/-/blob/debian/sid/src/unix/fs.c?ref_type=heads#L494
To reproduce, just dpkg-buildpackage from
dget -xu
https://deb.debian.org/debian/pool/main/libu/libuv1/libuv1_1.49.2-1.dsc
I'd be surprised if it concerns only libuv !
Please have a look, because the libuv maintainers already tried their
best.
My strong guess is that this is caused by the implied 64-bit
off_t after the time64 conversion. On i386, the file is
likely still built with a 32-bit off_t.
In the source line
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv" : "pwritev");
the uv__preadv_or_pwritev() function looks up the preadv() or
pwritev() symbols in glibc, but those expect a 32-bit ("long")
off_t, unlike preadv64() and pwritev64().
It appears that https://github.com/libuv/libuv/issues/4532
attempted to address the issue, but completely misunderstood
the problem, as this was a bug in libuv, not in gcc.
Ideally the library should avoid using dlsym() here, since
that makes it unportable. If it can't be avoided, it could
try to do something like
if ((sizeof(long)< sizeof(off_t))
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv64" : "pwritev64");
else
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv" : "pwritev");
Thank you, it works with that.
I linked your reply in the upstream issue.
This in turn makes it less portable to non-glibc
implementations like musl.
I suppose that unless upstream rewrites some parts, we will just add a patch
in the Debian package for now.
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 27 janv. 2025 à 17:41, Arnd Bergmann <<a href="mailto:
[email protected]">
[email protected]</a>> a écrit :<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jan 27, 2025, at 15:19, Jérémy Lal wrote:<br>
> Hi,<br>
><br>
> as discussed in<br>
> <a href="
https://github.com/libuv/libuv/issues/4678" rel="noreferrer" target="_blank">
https://github.com/libuv/libuv/issues/4678</a><br>
><br>
> and associated build failures <br>
> <a href="
https://buildd.debian.org/status/package.php?p=libuv1&suite=experimental" rel="noreferrer" target="_blank">
https://buildd.debian.org/status/package.php?p=libuv1&suite=experimental</a><br>
><br>
> It seems that gcc is doing something wrong with the offset parameter of <br>
> preadv, pwritev.<br>
> The same problem happens with optimization levels 0, 1, 2.<br>
><br>
> The call is made at<br>
> <a href="
https://salsa.debian.org/debian/libuv1/-/blob/debian/sid/src/unix/fs.c?ref_type=heads#L494" rel="noreferrer" target="_blank">
https://salsa.debian.org/debian/libuv1/-/blob/debian/sid/src/unix/fs.c?ref_type=heads#L494</a><br>
><br>
> To reproduce, just dpkg-buildpackage from<br>
> dget -xu <a href="
https://deb.debian.org/debian/pool/main/libu/libuv1/libuv1_1.49.2-1.dsc" rel="noreferrer" target="_blank">
https://deb.debian.org/debian/pool/main/libu/libuv1/libuv1_1.49.2-1.dsc</a><br>
><br>
> I'd be surprised if it concerns only libuv !<br>
> Please have a look, because the libuv maintainers already tried their best.<br>
My strong guess is that this is caused by the implied 64-bit<br>
off_t after the time64 conversion. On i386, the file is<br>
likely still built with a 32-bit off_t.<br>
In the source line<br>
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv" : "pwritev");<br>
the uv__preadv_or_pwritev() function looks up the preadv() or<br>
pwritev() symbols in glibc, but those expect a 32-bit ("long")<br> off_t, unlike preadv64() and pwritev64().<br>
It appears that <a href="
https://github.com/libuv/libuv/issues/4532" rel="noreferrer" target="_blank">
https://github.com/libuv/libuv/issues/4532</a><br>
attempted to address the issue, but completely misunderstood<br>
the problem, as this was a bug in libuv, not in gcc.<br>
Ideally the library should avoid using dlsym() here, since<br>
that makes it unportable. If it can't be avoided, it could<br>
try to do something like<br>
if ((sizeof(long)< sizeof(off_t))<br>
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv64" : "pwritev64");<br>
else<br>
p = dlsym(RTLD_DEFAULT, is_pread ? "preadv" : "pwritev");<br></blockquote><div><br></div><div>Thank you, it works with that.</div><div>I linked your reply in the upstream issue.</div><div><br></div><blockquote class="
gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This in turn makes it less portable to non-glibc<br>
implementations like musl.<br></blockquote><div><br></div><div>I suppose that unless upstream rewrites some parts, we will just add a patch</div><div>in the Debian package for now.<br></div><div><br></div></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)