Date: Sat, 30 Nov 2013 22:34:27 +0100 From: Michael Gmelin <freebsd@grem.de> To: "freebsd-ports@freebsd.org Ports" <freebsd-ports@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, David Chisnall <theraven@freebsd.org>, Brooks Davis <brooks@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org>, Matthias Andree <mandree@FreeBSD.org> Subject: Position independent code and global destructor order (devel/ice) Message-ID: <20131130223427.3d95ae7c@bsd64.grem.de> In-Reply-To: <20130827144507.385a552c@bsd64.grem.de> References: <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <A60BFADA-E358-4363-8BED-E154AB327C6B@FreeBSD.org> <20130626231741.497f7a9b@bsd64.grem.de> <20130626212833.GB91021@kib.kiev.ua> <20130627015602.7a437aad@bsd64.grem.de> <51CC411C.4060105@FreeBSD.org> <20130627140428.GI91021@kib.kiev.ua> <20130827144507.385a552c@bsd64.grem.de>
next in thread | previous in thread | raw e-mail | index | archive | help
We discussed this topic about half a year ago, but came to no conclusion. I CCed everyone who participated in the discussion back then. Since 10-RELEASE is around the corner and I'm trying to get devel/ice working on it, one more attempt: When -fPIC is used on objects that are linked into an executable (and not a shared library), the static destruction order guaranteed by the C++ standard is not followed. There is also no warning or error while building/linking. The end-result of this problem is subtle and will only surface on exit (at the end of runtime). When porting bigger projects (like Ice in my case), finding all those problems is really hard, since they're not reported at build time. It's not uncommon to set global CFLAGS in a build, and not every projects distinguishes between objects which will end up in shared libraries and those which will be linked to executables directly. In case of Ice this leads to crashes (bus error etc.) on exit, depending on the projects the results of this could be quite severe. The fix is to go through every Makefile of the project, basically creating a big patch that touches everything to work around this issue, hoping not to forget a single object file. Every user of the library and the generated code will have to do the same in their Makefiles/Cmakefiles/Jamfiles etc. It makes porting and using C++ code on FreeBSD hard and software that runs fine on other platforms will break for reasons people won't understand/will take them forever to debug. So is there anything that could be done to: a) Make -fPIC just work like it did before r211706? or if this is not an option. b) Report an error when linking the executable, so that objects built with -fPIC can't be used in that case/barf at compile time. I would appreciate any kind of constructive response at this point, the last I got was back in June: "I think that we could revert the termination calls to the functions from the dso being unloaded, but this is quite unfortunate, since it will restore the endless series of 'segfault at the process termination' reports." Thanks, Michael -- Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131130223427.3d95ae7c>