ELF load command address/offset not properly aligned

[ilya-lavrenov]

Describe the bug

Once 0.18 release is out, our build process started to fail with ELF load command address/offset not properly aligned. We use patchelf inside to add RPATH on Linux systems.

On CentOS all our libraries loading started to fail with such error, on Ubuntu 18.04 the issue is reproduced not in all cases (we don't have more details). But on Ubuntu 20.04 we have not seen any regressions.

Expected behavior

Works as before

patchelf --version output

0.18

[vsuorant]

Same here with ManyLinux containers that are based on AlmaLinux. 0.17.2.1 works, but 0.18 causes "ELF load command address/offset not properly aligned"

[Mic92]

We changed some alignment stuff in #475 to fix alignment on arm. Looks like this can cause regressions with older glibc versions?
Can you be more precise when this happens and how to reproduce this i.e. using docker? cc @brenoguim

[mathstuf]

It's not trivial, but VTK's CI has been affected by this. It's not trivial, but everything is in CI here: https://gitlab.kitware.com/vtk/vtk/-/jobs/8115134. The only difference that is meaningful to the error (to a first approximation) is a patchelf bump (see the issue I had filed above).

IIUC, patchelf is used to stuff non-blessed libraries into Python wheels so that they work "everywhere" given the limited set of libraries/ABIs PyPI can expect to exist in arbitrary Linux machines. DT_SONAME, DT_RUNPATH, and DT_NEEDED entries are all affected (the last to sync with the first's changes) before copying into the wheel. This may change section sizes.

I suspect just getting any old project that compiles C or C++ code, uses some "weird" external library, and puts that into a wheel using auditwheel will show this problem when trying to use said wheel.

[svenevs]

I suspect just getting any old project that compiles C or C++ code, uses some "weird" external library, and puts that into a wheel using auditwheel will show this problem when trying to use said wheel.

We ran into this with drake, I restored our old functionality of building patchelf from source in RobotLocomotion/drake#19265 to be able to help test if desired. There are instructions on the PR of how to do the build, but I do not think drake will be a convenient codebase for you all to try and identify what needs to be fixed, since iterating development will be very slow. That said, if you think you have something working and a commit is pushed somewhere, I can fairly easily run a canary build to see if the new change is working as desired. Hope that helps some!

[Mic92]

It looks like in #494 it's only breaking on arm64/s390x for centos. What cpu arch are you on?

[mayeut]

@Mic92, I saw the issue on x86_64. With #494, it just means that there are no tests that show the specific issue just now (or they only appear on arm64/s390x for some reason in the tests). #494 is meant for regressions not to be introduced once this issue is fixed (& a test added) since it only happens with some distros.