From owner-freebsd-ports@FreeBSD.ORG Sat Nov 30 21:41:10 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD3C7BF9 for ; Sat, 30 Nov 2013 21:41:10 +0000 (UTC) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 0F5DC1BC2 for ; Sat, 30 Nov 2013 21:41:09 +0000 (UTC) Received: (qmail 29468 invoked by uid 89); 30 Nov 2013 21:34:28 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@88.217.181.81) by mail.grem.de with ESMTPA; 30 Nov 2013 21:34:28 -0000 Date: Sat, 30 Nov 2013 22:34:27 +0100 From: Michael Gmelin To: "freebsd-ports@freebsd.org Ports" 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> <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> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , David Chisnall , Brooks Davis , Dimitry Andric , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 21:41:10 -0000 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