PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
rhurlin at gwdg.de
Tue Feb 11 09:46:27 UTC 2014
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
#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?
More information about the freebsd-ports