Awhile back, I mentioned that GCL was building in mock on my local machine, but was segfaulting on the koji builders. By dint of much experimentation, I now know what is going on. For the enlightenment of anybody who cares:
- GCL is linked with libtirpc. - libtirpc is linked with libselinux. - libselinux has a "constructor" function, init_lib(), that runs before main(). - init_lib() calls init_selinuxmnt() - init_selinuxmnt() checks that /sys/fs/selinux exists, has type SELINUX_MAGIC (see statfs(2)), and is not read-only. In mock on my home machine, all of this is true, so execution stops there; the library is initialized. - On the koji builders, /sys/fs/selinux does exist, but is read-only, so it fails the test. The code then does the same check on /selinux, but that doesn't exist. Due to both failures, selinuxfs_exists() is called to see if the running kernel even knows about selinuxfs. - selinuxfs_exists() walks through the contents of /proc/filesystems. That walk involves calls to getline(), which calls malloc(), and free(). - GCL has its own definitions of malloc() and free(), but those definitions require that address randomization be turned off. GCL accomplishes this with a call to personality() early in main(), but the libselinux initializer runs before main(), resulting in GCL segfaulting in free(). So the issue isn't really mock on my machine vs. koji: it is systems where /sys/fs/selinux is mounted read-write versus those where it is mounted read-only or not mounted at all. One workaround is to invoke GCL at build time with setarch -R gcl <args>, but that means any GCL users who do not have /sys/fs/selinux mounted read-write will have to do the same. I can't help but think that one should be very careful about what code is executed in an __attribute__((constructor)) function in a library, though. In particular, invoking malloc() and free() just doesn't seem like a great idea; there are lots of executables that use alternate malloc()/free() functions, so perturbing the heap before they have a chance to be set up can cause problems. In the case of libselinux, it seems to me that such invocations are not necessary, although I have not yet made the effort to code up a replacement. I will try to do that when I have a little free time. Sadly, even with the setarch workaround, gcl still fails to build due to a ppc64le-specific issue, which I have reported upstream. Hopefully a fix will be available soon. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
