The fix for cmake is to use -no-system-libs, which seems to correctly compile cmake's own choice of several libraries, including liblzma, statically into the cmake binary. ![]() As I understand it, the patch + is likely to be applied in 5.2.7 in the stable branch - whenever that happens to be released.įor Easybuild-Easyconfigs, I would suggest reverting the guess at #15856 and implementing the recommended upstream xz fix instead.Īs far as Maneage is concerned, we've separated out the CentOS 7 error in handling xz from our own bug in handling the build of cmake. Commit 913ddc55 has a detailed explanation of the problem and the fix. See commit 913ddc55 'liblzma: Vaccinate against an ill patch from RHEL/CentOS 7' and commit 17485e88. My guess is that doing a hack of glibc/ pthread would be more un-sustainable than the current xz hack, though I'm again just guessing.ĭraft fixes can be seen on the xz experimental git branch. We have a task set for installing glibc itself. Maneage does currently depend on the system's glibc, so it's less independent from the host system than we would like. $ nm -D /lib/x86_64-linux-gnu/libpthread.so.0 |grep -C2 pthread_getaffinityĠ0000000xxxxxxxx W W T T T T any case, you do seem to be right: the fault is not that of cmake or openssl, it appears rather to be a pthread/ glibc issue. $ nm -D /lib64/libpthread.so.0|grep -C2 pthread_getaffinityĠ0000000xxxxxxxx T pthread_getaffinity_npĠ0000000xxxxxxxx T pthread_getconcurrency The fixes need to be handled in the parts of the system where people most expect them to be handled, and where expertise and understanding on a package is coordinated - which is upstream in the particular affected packages. In either case, having a list of known hacks in 'easybuild-easyconfigs' is a useful workaround (and it's where I found info that seems to handle this bug), but it's not a sustainable way to develop the FOSS ecosystem. I guess CentOS7 developers are the ones who should make the effort of getting cmake, openssl, and any other affected packages fixed. ![]() If we knew the list of all programs that incorrectly depend on non-maintainable parts of the xz/libzma ABI in the CentOS7 context, and if we could persuade all their developers to fix this dependence, then that would, I presume, be an alternative to xz making the hack proposed here. CentOS7 systems will gradually be superseded, but they won't disappear suddenly.Īs I understand it, both cmake and openssl (through openssl-devel) created dependences on versions or functions in ABIs that they were not supposed to create. Even though this looks like a CentOS7 specific problem, I assume that #tukaani/xz developers have an interest in keeping xz portable, and in keeping widely used programs that depend on xz portable in their dependence on xz, even if, as seems to be the case here, those programs made some non-portable or non-sustainable hacks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |