From owner-freebsd-ports@FreeBSD.ORG Tue Feb 11 09:46:27 2014 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 7FFF9DF; Tue, 11 Feb 2014 09:46:27 +0000 (UTC) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A1951CEA; Tue, 11 Feb 2014 09:46:26 +0000 (UTC) Received: from gate.nw-fva.de ([134.76.242.1] helo=pc028.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1WD9v4-0003cD-Af; Tue, 11 Feb 2014 10:46:23 +0100 Message-ID: <52F9F16E.6040809@gwdg.de> Date: Tue, 11 Feb 2014 10:46:22 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matthias Andree , freebsd-ports@freebsd.org Subject: Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD References: <706bd12f0dfa77b042ec36685b08c572.squirrel@mx.waitman.net> <20140209223228.GR80056@ithaqua.etoilebsd.net> <20140209223830.GS80056@ithaqua.etoilebsd.net> <53abb5a25f86f9c10fabcabb83e4157d.squirrel@mx.waitman.net> <20140210104037.7dcaf6b0@X220.alogt.com> <52F895F3.6070606@FreeBSD.org> <20140211010834.384f8a34@X220.alogt.com> <52F95186.9010503@FreeBSD.org> <52F9E549.4070205@gwdg.de> <52F9E8DB.6070301@gmx.de> In-Reply-To: <52F9E8DB.6070301@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Koop Mast X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 09:46:27 -0000 Am 11.02.2014 10:09 (UTC+1) schrieb Matthias Andree: > (stripping Cc: list down a bit) > > Am 11.02.2014 09:54, schrieb Rainer Hurling: > >>> *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* >> >> I just tried RawTherapee after rebuilding devel/glib20 with the iconv >> related patch, and it works flawlessly! Some small test with filters and >> converting also seem to work. >> >> This is on HEAD r261632 amd64. RawTherapee is build with gcc48 and >> OpenMP support. >> >> Once, if there is an official patch in the ports tree, is it recommended >> to rebuild all dependencies of glib20? > > Unless there will be other changes to glib20 outside the patch, that > would not be required. The patch to glib20 does not change its ABI to > applications (its 'consumers', so to say), so just reinstalling glib20 > so that it uses libiconv rather than libc for iconv*() functions would > suffice (and on FreeBSD 8.x and 9.x, glib20 always uses libiconv.) > >>> 1. download Koop's patch to glib20 from >>> >>> >>> 2. apply the patch, build and install glib20 with the patch >>> >>> 3. try *and report* if that fixes the rawtherapee crashes? >> >> Many thanks to not give up with this issue! RawTherapee is a great raw >> processor for both, amateurs and professionals. And it is one of that >> great programs, we want to use on different platforms (including Windows). > > Unfortunately the code base is less sound than we would like for a > portable application. I've read a few upstream crash issues and RT > seems a pig to debug. I just recognized another issue, what I think is not intended. Newest graphics/rawtherapee installs and uses devel/libc++. This wanted behaviour is included in the ports Makefile for OpenMP reasons. As a side effect, other ports with c++ usage also seem to grab devel/libc++, even if devel/libc++ is not mentioned in the ports Makefile. You can try this by rebuilding and reinstalling e.g. graphics/darktable. This leads to #pkg info -r libc++-200683 libc++-200683: rawtherapee-4.0.12_1 darktable-1.2.3_3 #ldd /usr/local/bin/darktable | grep c++ libc++.so.1 => /usr/local/lib/libc++.so.1 (0x4690e000) I don't know, if this is harmless or if this should not happen? Once again, this is on HEAD r261632 amd64. Any comments or ideas? Regards, Rainer