On Fri, Apr 11, 2014 at 09:15:35AM -0400, Josh Boyer wrote: > Seems they were enabled for RPM in rawhide and now a mock chroot fails > to init because RPM explodes. This is from a noarch (which is run on > an ARM builder) build from a scratch build. For -fsanitize=address (and -fsanitize=thread), it is usually needed that if some shared library is instrumented with that, the binary linking against that or especially dlopening such shared libraries is also instrumented (the same). So, I'd strongly recommend against enabling -fsanitize=address for building of shared libraries some other packages might need to dlopen, do it only in your own scratch builds, not in anything you install into rawhide. The thing with these two is that libasan.so (or libtsan.so) needs to be initialized very early, before other shared libraries that might be instrumented run their constructors. Also, -fsanitize=address has been tested much more on x86_64/i686 than on other architectures. And, -fsanitize=address is incompatible with -fsanitize=thread, you can only have one kind of instrumentation from these in the whole process. -fsanitize=undefined instrumented shared libraries can be dlopened just fine, but don't forget to disable the instrumentations say after beta. Jakub -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
