adoptium/ci-jenkins-pipelines

Adoptium DevKit is not reproducible with a 3rd party built DevKit due to library dynsym order differences

andrew-m-leonard opened this issue · 2 comments

The current Adoptium DevKit when compared to an equivalent externally built DevKit produces non-identical libraries, differing due to the ordering of the .dynsym section.
The cause has been tracked down to the Adoptium DevKit bootstrapping the build of binutils using gcc 4.8.5, compared to a later gcc 8.5 or 11.2 used in the 3rd party comparison test.

We need to "bootstrap" the DevKit make, to build itself as a "bootstrap-devkit" with the supplied gcc, then build the "final" DevKit using the "bootstrap-devkit".

sxa commented

At this point we should consider using a later OS for generating the devkit and running the builds. RHEL8/C8S come with GCC 8.5 out of the box which would remove the need for such a bootstrap.. Given how the devkit works, building on a later OS should not impact our compatibility with RHEL7/CentOS7 systems.

At this point we should consider using a later OS for generating the devkit and running the builds. RHEL8/C8S come with GCC 8.5 out of the box which would remove the need for such a bootstrap.. Given how the devkit works, building on a later OS should not impact our compatibility with RHEL7/CentOS7 systems.

Yes agree, if we can do that we would actually be consistent with other Vendors who work on the same major versions.

I would still recommend the bootstrap however, as we cannot forsee other such gcc behavioural changes, and it is a straight forward change.