I finally did a reprotest build of systemd on armhf to try and figure
out why it doesn't build reproducibly... but it built reproducibly...

My test did not test building with a 64-bit kernel (it was using a
32-bit kernel in both cases), whereas the tests.reproducible-builds.org infrastructure systematically tests one build with 64-bit kernel and one
with a 32-bit kernel...

The build done with a 32-bit kernel includes a reference to
"arm_fadvise64_64", whereas the build with a 64-bit kernel does
not:

https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/armhf/diffoscope-results/systemd.html

Does fadvise (posix_fadvise?) on 64-bit not need any special handling,
whereas on 32-bit needs a wrapper function of some kind?

Not sure exactly where this behavior comes from(quite possibly in a
dependent library and not systemd itself), but the build features should
be determined from the userland (armhf) that it is built in, and not
from which kernel is running.


Sorry I don't have more conclusive results, but at least this suggests a direction to look into.


live well,
vagrant

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYbeZZQAKCRDcUY/If5cW qpYOAP0eKaPGxgTtk1Iyk6tWwI+2c9Emrf/LOEMvQjSoyvUzlwEA/8LGXofmKxoW f/JD61Qxhj5Pp1aE5NX9PMY0wj+VTQE=gQba
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Dec 13, 2021 at 8:05 PM Vagrant Cascadian <vagrant@reproducible-builds.org> wrote:

I finally did a reprotest build of systemd on armhf to try and figure
out why it doesn't build reproducibly... but it built reproducibly...

My test did not test building with a 64-bit kernel (it was using a
32-bit kernel in both cases), whereas the tests.reproducible-builds.org infrastructure systematically tests one build with 64-bit kernel and one
with a 32-bit kernel...

The build done with a 32-bit kernel includes a reference to "arm_fadvise64_64", whereas the build with a 64-bit kernel does
not:

https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/armhf/diffoscope-results/systemd.html

Does fadvise (posix_fadvise?) on 64-bit not need any special handling, whereas on 32-bit needs a wrapper function of some kind?

There should not be any difference between which kernel you are running
on, but there is a difference in behavior between architectures you build for.

fadvise is a strange syscall, since it was introduced incorrectly
multiple times,
and depending on the architecture you have different levels of fallbacks:

- fadvise64 was meant as the generic syscall, but it only works right on 64-bit
architectures, as the length argument is truncated to 4GB otherwise, and the
'offset' may be passed in the wrong registers on certain 32-bit architectures - fadvise64_64 was introduced to solve the problem with the length argument,
but does not solve the other one
- arm_fadvise64_64 (and the same thing on i386, nds32, csky, sh and maybe more)
deals with the problem of passing 64-bit arguments in pairs of registers, by
reordering the arguments.

It sounds like there is a compile-time check in systemd that determines which of these to use based on the host architecture, rather than the target architecture.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: vagrant@reproducible-builds.org (Vagrant Cascadian)
Copy: reproducible-builds@lists.alioth.debian.org
Copy: debian-arm@lists.debian.org (ARM)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------00nkGY9NhfolI2trNW7XCVq1
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTMuMTIuMjEgMjA6NDQsIEFybmQgQmVyZ21hbm4gd3JvdGU6DQo+IEl0IHNvdW5kcyBs aWtlIHRoZXJlIGlzIGEgY29tcGlsZS10aW1lIGNoZWNrIGluIHN5c3RlbWQgdGhhdCBkZXRl cm1pbmVzIHdoaWNoDQo+IG9mIHRoZXNlIHRvIHVzZSBiYXNlZCBvbiB0aGUgaG9zdCBhcmNo aXRlY3R1cmUsIHJhdGhlciB0aGFuIHRoZSB0YXJnZXQNCj4gYXJjaGl0ZWN0dXJlLg0KDQpJ ZiB0aGF0IHdhcyB0aGUgY2FzZSwgc2hvdWxkIHdlIHNlZSB0aGUgc2FtZSBwcm9ibGVtIHdp dGggYW4gYW1kNjQgDQprZXJuZWwgYW5kIGkzODYgdXNlcmxhbmQ/DQoNCg==

--------------00nkGY9NhfolI2trNW7XCVq1--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmHBL/kFAwAAAAAACgkQauHfDWCPItzy aBAAhlK7Y4NBRu9QJGYwahMTurt0Ovp8OPCfDJoSf7RZSFJjPCSRYIHG44eRllYD/GpSUQDW9HNF JyUEy3YqfmCEsx+0Ht5DVHqcdSpLx2zn7aiFlz0pvfRBfBduLg9pXIaMJ5+kC3paVUBOGrZATieS ozy2XHnO9qQTHh7fYeuoEJ1XS/Tce37dHyVEXGke9J9HoMULiGEmxCmUGitC09ih1iT6PSjLwdL/ dEQ1qFz53RsPlAiPWhd7AgNNcL2wb7jOarPVyuWlzIu7+q0yJs+BI90vUMgDcPpVCyg1la8jdV4I oLmuKTyRwo2egAc2eAghduedXKMTd+I9bMt0fUE6dzekl7Jf+5e7NIaHS45Zc/40fLCSh/lXhAZB 2Kg+Fu9WZyAWe2okpBfJPzCBp4CP9Qghd3z1zznSO8VwU1jXjFJaNzTOG5n2J1dnOqcU/WxGJz8U 5sEtngh6KG58Wdf59ii5bJ3a/Ng6PjHQgh0L/kc3M0iYoX/++q9NlRp4BjR/xkpVGELD+ALgMi2e +/BC2Rjwb3yldLTNXSn8BPBOJr8A+/ZTPCJca1GMgmZ15umRJsobX4lUBQRIj79zmaQ+/2TlgVx/ /1C0MWfLIVlR31DB6wW9jloPK19+kjQjQebdcpMYYGsaMOwKV+prYLOv/xpSLLjQz5tmuMS9z1DR rZs=
=6pW/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Dec 21, 2021 at 2:38 AM Michael Biebl <biebl@debian.org> wrote:

On 13.12.21 20:44, Arnd Bergmann wrote:

It sounds like there is a compile-time check in systemd that determines which
of these to use based on the host architecture, rather than the target architecture.

If that was the case, should we see the same problem with an amd64
kernel and i386 userland?

It depends on how it's written, they use different exceptions:

- you need normal fadvise64() on 64-bit
- you need fadvise64_64() on x86-32 and most other 32-bit platforms
- you need arm_fadvise64_64() on arm32 only

So anything that explicitly references arm_fadvise64_64() would have to
have a detection for building for 32-bit arm specifically, rather than just detecting whether it's building for 32-bit or 64-bit.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)