Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 12.02.2014 07:20, schrieb Erich Dollansky: Hi, On Wed, 12 Feb 2014 06:49:28 +0100 Christoph Moench-Tegeder c...@burggraben.net wrote: ## Rainer Hurling (rhur...@gwdg.de): Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? Exactly. I do not know if this related but my gimp did not work anymore after I successfully have had rawtherapee installed. After recompiling gimp-app and reinstalling it, also gimp works again. For me, Gimp still works after installation of rawtherapee, without recompiling gimp-app, on 9.2-RELEASE. I hadn't installed gimp on 10.0 prior to installing rawtherapee, but pkg install gimp-app also gives me a working gimp on 10.0-RELEASE-amd64. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 10.02.2014 23:24 (UTC+1) schrieb Matthias Andree: Am 10.02.2014 18:08, schrieb Erich Dollansky: it depends obviously on factors we do not really know. I also have had a working rawtherapee a few weeks ago. Just the last update of the ports tree killed it again. Greetings, thanks to Waitman who debugged things over the weekend, we have a prime suspect, and that's an insufficient iconv() set on FreeBSD 10 and newer that for some users makes glib20 and glibmm together throw an exception when asked to convert UTF-8 to wchar_t that Rawtherapee does not catch nor report. We may also have a solution, which I am asking you to test. I also whish to thank Waitman for his debugging work :) *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? 1. download Koop's patch to glib20 from http://people.freebsd.org/~kwm/glib-iconv-hell.diff 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). Greetings, Rainer Thanks. Best regards Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
(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 http://people.freebsd.org/~kwm/glib-iconv-hell.diff 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. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
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 http://people.freebsd.org/~kwm/glib-iconv-hell.diff 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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
On Mon, 10 Feb 2014 23:24:06 +0100 Matthias Andree wrote: Am 10.02.2014 18:08, schrieb Erich Dollansky: it depends obviously on factors we do not really know. I also have had a working rawtherapee a few weeks ago. Just the last update of the ports tree killed it again. Greetings, thanks to Waitman who debugged things over the weekend, we have a prime suspect, and that's an insufficient iconv() set on FreeBSD 10 and newer that for some users makes glib20 and glibmm together throw an exception when asked to convert UTF-8 to wchar_t that Rawtherapee does not catch nor report. We may also have a solution, which I am asking you to test. *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* 1. download Koop's patch to glib20 from http://people.freebsd.org/~kwm/glib-iconv-hell.diff You might want to mention in the iconv:wchar_t comment that the actual use of WCHAR_T is in glibmm. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
## Matthias Andree (mand...@freebsd.org): *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* I'm not able to reproduce the original crash (even when playing with LC_CTYPE and umlauts), and I do not see regressions from that glib patch. Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 11.02.2014 20:27, schrieb Christoph Moench-Tegeder: ## Matthias Andree (mand...@freebsd.org): *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* I'm not able to reproduce the original crash (even when playing with LC_CTYPE and umlauts), and I do not see regressions from that glib patch. Hmm, is it right, that your base and port (last commit with gcc48 dependency) are very recent? Just to be sure ;) Greetings, Rainer Regards, Christoph ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
## Rainer Hurling (rhur...@gwdg.de): *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* I'm not able to reproduce the original crash (even when playing with LC_CTYPE and umlauts), and I do not see regressions from that glib patch. Hmm, is it right, that your base and port (last commit with gcc48 dependency) are very recent? My base is 10.0-RELEASE, and the port is totally recent (rawtherapee-4.0.12_1, Makefile r343191). converters/libiconv hadn't been installed until right now. OTOH I'm very careful with using umlauts in file names etc. (been bitten once too often), even as my environment is UTF-8, so I might have missed that issue when testing. Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 11.02.2014 21:55, schrieb Christoph Moench-Tegeder: ## Rainer Hurling (rhur...@gwdg.de): *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* I'm not able to reproduce the original crash (even when playing with LC_CTYPE and umlauts), and I do not see regressions from that glib patch. Hmm, is it right, that your base and port (last commit with gcc48 dependency) are very recent? My base is 10.0-RELEASE, and the port is totally recent (rawtherapee-4.0.12_1, Makefile r343191). converters/libiconv hadn't been installed until right now. OTOH I'm very careful with using umlauts in file names etc. (been bitten once too often), even as my environment is UTF-8, so I might have missed that issue when testing. Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? Regards, Christoph ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 11.02.2014 10:46, schrieb Rainer Hurling: 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 I think that is an artifact of the same library being installed in two places. As far as I understood bapt@ (Cc'd), the idea is that the port mirrors the c++ library we have in the base system, and both are compatible, and particularly, they have the same ABI. Basically we need the libc++ headers to make use of libc++'s inline namespace so that rawtherapee references libc++'s symbols (in the std::__1:: namespace) rather than libstdc++ (in the std:: namespace). If you are willing to experiment, you should be able to deinstall libc++ now, and both darktable and rawtherapee should continue to work with the base libc++. #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) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 11.02.2014 22:10, schrieb Rainer Hurling: Am 11.02.2014 21:55, schrieb Christoph Moench-Tegeder: My base is 10.0-RELEASE, and the port is totally recent (rawtherapee-4.0.12_1, Makefile r343191). converters/libiconv hadn't been installed until right now. OTOH I'm very careful with using umlauts in file names etc. (been bitten once too often), even as my environment is UTF-8, so I might have missed that issue when testing. Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? I am also using 10.0-RELEASE. So the question is if someone has (had) problems with rawtherapee on 10-*STABLE* (OSVERSION = 1000500) while glib20 is still at glib-2.36.3_1? Please speak up if you are one of them! Because if so that might suggest we are facing regressions from 10-RELEASE to 10-STABLE and from 10-RELEASE to 11-STABLE. That might warrant investigation. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
On Tue, 11 Feb 2014 23:14:05 +0100 Matthias Andree wrote: Am 11.02.2014 22:10, schrieb Rainer Hurling: Am 11.02.2014 21:55, schrieb Christoph Moench-Tegeder: My base is 10.0-RELEASE, and the port is totally recent (rawtherapee-4.0.12_1, Makefile r343191). converters/libiconv hadn't been installed until right now. OTOH I'm very careful with using umlauts in file names etc. (been bitten once too often), even as my environment is UTF-8, so I might have missed that issue when testing. Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? I am also using 10.0-RELEASE. So the question is if someone has (had) problems with rawtherapee on 10-*STABLE* (OSVERSION = 1000500) while glib20 is still at glib-2.36.3_1? Please speak up if you are one of them! Because if so that might suggest we are facing regressions from 10-RELEASE to 10-STABLE and from 10-RELEASE to 11-STABLE. That might warrant investigation. 10-RELEASE shipped with a faulty implementation of WCHAR_T conversion, so it doesn't return an error but it doesn't do the right thing either. This implementation has been backed out again after the release, so iconv_open returns -1 again when you request WCHAR_T conversion. The crash happens when an application doesn't test for errors and assumes the return value is a valid pointer. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
## Rainer Hurling (rhur...@gwdg.de): Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? Exactly. Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi, On Wed, 12 Feb 2014 06:49:28 +0100 Christoph Moench-Tegeder c...@burggraben.net wrote: ## Rainer Hurling (rhur...@gwdg.de): Thanks for this info. So perhaps your situation is like the one, mandree@ observed on his 10.0 box: no crashes without the patch? Exactly. I do not know if this related but my gimp did not work anymore after I successfully have had rawtherapee installed. After recompiling gimp-app and reinstalling it, also gimp works again. Erich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 11.02.2014 23:02 (UTC+1) schrieb Matthias Andree: Am 11.02.2014 10:46, schrieb Rainer Hurling: 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 I think that is an artifact of the same library being installed in two places. As far as I understood bapt@ (Cc'd), the idea is that the port mirrors the c++ library we have in the base system, and both are compatible, and particularly, they have the same ABI. Basically we need the libc++ headers to make use of libc++'s inline namespace so that rawtherapee references libc++'s symbols (in the std::__1:: namespace) rather than libstdc++ (in the std:: namespace). If you are willing to experiment, you should be able to deinstall libc++ now, and both darktable and rawtherapee should continue to work with the base libc++. Yes, this presumption is right. After 'pkg delete -f libc++-200683 libcxxrt-20131225_1' I am able to use rawtherapee furthermore. So ports like RawTherapee would also work, when devel/libc++ and devel/libcxxrt would be deinstalled right after successfull installation of the port. My problem is more the other side around: Why do ports like e.g. graphics/darktable pick up the headers from devel/libc++ instead of the base ones? In darktable there is no devel/libc++ dependency specified. Installing graphics/darktable, while devel/libc++ is already installed, creates a dependency. This will jumble up the dependency list in ports/packages and should not happen. Only ports with a declared dependency on devel/libc++ should use this port. #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) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 10.02.2014 03:40, schrieb Erich Dollansky: Hi, On Sun, 9 Feb 2014 07:07:00 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote: USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 as you might have expected, this also fixes rawtherapee on 10.0. Interesting™, thanks for the feedback. Meaning: why does it /not/ crash for me on 10.0? Who made glib use libiconv-from-ports (I believe I used default options for all ports on 10.0, and most are actually binaries installed with pkg), or did glib20 automatically pick up libiconv or or or... Will have to investigate tonight. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi, On Mon, 10 Feb 2014 10:03:47 +0100 Matthias Andree mand...@freebsd.org wrote: Am 10.02.2014 03:40, schrieb Erich Dollansky: On Sun, 9 Feb 2014 07:07:00 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote: USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 as you might have expected, this also fixes rawtherapee on 10.0. Interesting™, thanks for the feedback. Meaning: why does it /not/ crash for me on 10.0? Who made glib use libiconv-from-ports (I believe I used default options for all ports on 10.0, and most are actually binaries installed with pkg), or did glib20 automatically pick up libiconv or or or... Will have to investigate tonight. it depends obviously on factors we do not really know. I also have had a working rawtherapee a few weeks ago. Just the last update of the ports tree killed it again. Erich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 10.02.2014 18:08, schrieb Erich Dollansky: it depends obviously on factors we do not really know. I also have had a working rawtherapee a few weeks ago. Just the last update of the ports tree killed it again. Greetings, thanks to Waitman who debugged things over the weekend, we have a prime suspect, and that's an insufficient iconv() set on FreeBSD 10 and newer that for some users makes glib20 and glibmm together throw an exception when asked to convert UTF-8 to wchar_t that Rawtherapee does not catch nor report. We may also have a solution, which I am asking you to test. *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:* 1. download Koop's patch to glib20 from http://people.freebsd.org/~kwm/glib-iconv-hell.diff 2. apply the patch, build and install glib20 with the patch 3. try *and report* if that fixes the rawtherapee crashes? Thanks. Best regards Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id () from
/usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained installed
on the destination machine), because we need to match the libraries
that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now, and
use GCC 4.8 on all systems. RawTherapee is somewhat demanding,
especially at higher optimization level, and kills the 10.0-RELEASE
base clang and Port GCC 4.6 and 4.7, all with internal compiler
errors. Since GCC 4.8 worked for me, I did not bother to send Gerald
the details.
We may want to retry with clang if we've got the next clang version.
Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should be
set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from makefile). but
still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0;
std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4` testglib.cpp
$ ./testglib
3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
#4 0x00080086ed2f in Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
#5 0x00080087bcc2 in Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1
#6 0x00401de0 in Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158
#7 0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb 8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA amd64
$ ldd testglib
testglib:
libglibmm-2.4.so.1 = /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
libgobject-2.0.so.0 = /usr/local/lib/libgobject-2.0.so.0
(0x800a9d000)
libglib-2.0.so.0 =
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id () from
/usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained installed
on the destination machine), because we need to match the libraries
that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now, and
use GCC 4.8 on all systems. RawTherapee is somewhat demanding,
especially at higher optimization level, and kills the 10.0-RELEASE
base clang and Port GCC 4.6 and 4.7, all with internal compiler
errors. Since GCC 4.8 worked for me, I did not bother to send Gerald
the details.
We may want to retry with clang if we've got the next clang version.
Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should be
set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from makefile). but
still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0;
std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4` testglib.cpp
$ ./testglib
3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
#4 0x00080086ed2f in Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
#5 0x00080087bcc2 in Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1
#6 0x00401de0 in Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158
#7 0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb 8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA amd64
$ ldd testglib
testglib:
libglibmm-2.4.so.1 = /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
libgobject-2.0.so.0 = /usr/local/lib/libgobject-2.0.so.0
(0x800a9d000)
libglib-2.0.so.0 =
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id ()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained installed
on the destination machine), because we need to match the
libraries that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now, and
use GCC 4.8 on all systems. RawTherapee is somewhat demanding,
especially at higher optimization level, and kills the 10.0-RELEASE
base clang and Port GCC 4.6 and 4.7, all with internal compiler
errors. Since GCC 4.8 worked for me, I did not bother to send
Gerald
the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should be
set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from makefile).
but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib
3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details. This GDB was configured as
x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb 8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA amd64
$ ldd testglib
testglib:
libglibmm-2.4.so.1 = /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id ()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained installed
on the destination machine), because we need to match the
libraries that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now, and
use GCC 4.8 on all systems. RawTherapee is somewhat demanding,
especially at higher optimization level, and kills the 10.0-RELEASE
base clang and Port GCC 4.6 and 4.7, all with internal compiler
errors. Since GCC 4.8 worked for me, I did not bother to send
Gerald
the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should be
set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from makefile).
but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib
3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details. This GDB was configured as
x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb 8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA amd64
$ ldd testglib
testglib:
libglibmm-2.4.so.1 = /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id ()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained installed
on the destination machine), because we need to match the
libraries that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now, and
use GCC 4.8 on all systems. RawTherapee is somewhat demanding,
especially at higher optimization level, and kills the 10.0-RELEASE
base clang and Port GCC 4.6 and 4.7, all with internal compiler
errors. Since GCC 4.8 worked for me, I did not bother to send
Gerald
the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should be
set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from makefile).
but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib
3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details. This GDB was configured as
x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id
()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware
Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained
installed on the destination machine), because we need to match
the libraries that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now,
and use GCC 4.8 on all systems. RawTherapee is somewhat
demanding, especially at higher optimization level, and kills
the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with
internal compiler errors. Since GCC 4.8 worked for me, I did
not bother to send Gerald
the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should
be set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from
makefile). but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing
ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks theme
ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format.
I've
experimented with various examples and they all crash. Currently
exploring this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib 3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying and show warranty for details. This GDB was configured as
x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base
(
const)(std::__1::ios_base), std::__1::__iom_t5 const, double
const) ( a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )}
0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at testglib.cpp:9
(gdb)
$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1
r261643:
Sat Feb 8 22:11:05 PST 2014
root akira waitman
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in std::__1::locale::id::__next_id
()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware
Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained
installed on the destination machine), because we need to match
the libraries that the requisites use (Glibmm for one).
I have given up on compiling RawTherapee with clang++ for now,
and use GCC 4.8 on all systems. RawTherapee is somewhat
demanding, especially at higher optimization level, and kills
the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with
internal compiler errors. Since GCC 4.8 worked for me, I did
not bother to send Gerald
the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib should
be set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required by
rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from
makefile). but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing
ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks theme
ported to gtk3
3) I believe i'be narrowed the crash down to Glib::ustring::format.
I've
experimented with various examples and they all crash. Currently
exploring this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib 3.14286
Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying and show warranty for details. This GDB was configured as
x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base
(
const)(std::__1::ios_base), std::__1::__iom_t5 const, double
const) ( a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base )}
0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3= 0x7fffd860:
3.1428571428571428)
at
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in
std::__1::locale::id::__next_id
()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware
Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained
installed on the destination machine), because we need to
match the libraries that the requisites use (Glibmm for
one).
I have given up on compiling RawTherapee with clang++ for
now, and use GCC 4.8 on all systems. RawTherapee is
somewhat demanding, especially at higher optimization level,
and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
4.7, all with
internal compiler errors. Since GCC 4.8 worked for me, I
did not bother to send Gerald the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system
test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib
should be set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required
by rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from
makefile). but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing
ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
theme ported to gtk3
3) I believe i'be narrowed the crash down to
Glib::ustring::format.
I've
experimented with various examples and they all crash. Currently
exploring this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type
show
copying and show warranty for details. This GDB was configured
as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*)
()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5,
double(std::__1::ios_base
(
const)(std::__1::ios_base), std::__1::__iom_t5 const, double
const) ( a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base
)}
0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3=
0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, Feb 09, 2014 at 06:51:28AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in
std::__1::locale::id::__next_id
()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware
Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained
installed on the destination machine), because we need to
match the libraries that the requisites use (Glibmm for
one).
I have given up on compiling RawTherapee with clang++ for
now, and use GCC 4.8 on all systems. RawTherapee is
somewhat demanding, especially at higher optimization level,
and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
4.7, all with
internal compiler errors. Since GCC 4.8 worked for me, I
did not bother to send Gerald the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system
test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib
should be set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required
by rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from
makefile). but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing
ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
theme ported to gtk3
3) I believe i'be narrowed the crash down to
Glib::ustring::format.
I've
experimented with various examples and they all crash. Currently
exploring this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type
show
copying and show warranty for details. This GDB was configured
as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*)
()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5,
double(std::__1::ios_base
(
const)(std::__1::ios_base), std::__1::__iom_t5 const,
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
wrote:
Am 05.02.2014 21:08, schrieb Dimitry Andric:
#17 0x484c0ee0 in
std::__1::locale::id::__next_id
()
from /usr/local/lib/libc++.so.1
Hmm, is this a ports version of libc++? I was not aware
Baptiste
had already committed this? :)
Yes, it is (as a build requisite, but apparently remained
installed on the destination machine), because we need to
match the libraries that the requisites use (Glibmm for
one).
I have given up on compiling RawTherapee with clang++ for
now, and use GCC 4.8 on all systems. RawTherapee is
somewhat demanding, especially at higher optimization level,
and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
4.7, all with
internal compiler errors. Since GCC 4.8 worked for me, I
did not bother to send Gerald the details.
We may want to retry with clang if we've got the next clang
version. Feel free to use Rawtherapee as compiler system
test ;)
try with something like this in libmap.conf libc++.so.1
/usr/local/lib/libc++.so.1
If that fixes the problem, then a rpath with /usr/local/lib
should be set while building the port
Hmm, I am not very familiar with libmapping. After adding it to
/etc/libmap.conf I get
#rawtherapee
Shared object /usr/local/lib/libc++.so.1 not found, required
by rawtherapee
Thanks for the tip,
Rainer
regards, Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Here are a few points regarding rawtherapee on 11.0-CURRENT.
1) it builds fine using clang (removing all the gcc4.8 from
makefile). but still crashes the same.
2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'
can be eliminated by installing
ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
theme ported to gtk3
3) I believe i'be narrowed the crash down to
Glib::ustring::format.
I've
experimented with various examples and they all crash. Currently
exploring this problem to see what's up.. anyone have some clue?
here is a sample:
#include iostream
#include iomanip
#include glibmm.h
int main() {
double value = 22.0 / 7.0; std::cout value std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout test std::endl;
}
$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type
show
copying and show warranty for details. This GDB was configured
as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0 0x000801e313ba in kill () from /lib/libc.so.7
#1 0x000801e30069 in abort () from /lib/libc.so.7
#2 0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3 0x00080085de68 in Glib::ConvertError::throw_func(_GError*)
()
from /usr/local/lib/libglibmm-2.4.so.1 #4 0x00080086ed2f in
Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1 #5 0x00080087bcc2 in
Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1 #6 0x00401de0 in
Glib::ustring::formatstd::__1::ios_base
(std::__1::ios_base), std::__1::__iom_t5,
double(std::__1::ios_base
(
const)(std::__1::ios_base), std::__1::__iom_t5 const, double
const) ( a1= 0x401e50: {std::__1::ios_base (std::__1::ios_base
)}
0x401e50
std::__1::fixed(std::__1::ios_base), a2=..., a3=
0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
0x00401696 in main () at
Re: graphics/rawtherapee: r342622 crashes on HEAD
On 09 Feb 2014, at 16:07, Waitman Gobble uzi...@da3m0n8t3r.com wrote: ... ok, so changing the Makefile for port/devel/glib20 USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 finally solves the problem with graphics/rawtherapee. The program works on my FreeBSD 11.0-CURRENT machine without crashing. (although it's not really a rawtherapee issue, it's related to glib20). So, we can cross another one off clang's list? :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 09.02.2014 23:38, schrieb Baptiste Daroussin: Conversion from character set 'UTF-8' to 'WCHAR_T' is not supported I don't know if glib or glibmm should gain USES=libiconv:wchar_t but that should fix it. Thanks to Waitman for debugging this - very useful work indeed. Now since that USES= on glib20 fixes the unhandled exceptions on FreeBSD 11, how do we solve this? Are we making glib20 use the ports iconv by means of USES=libiconv:wchar_t, or is there a way that I can check from the Rawtherapee Makefile, so that I can mark Rawtherapee BROKEN or IGNORE in case glib20 was built without wchar_t support? signature.asc Description: OpenPGP digital signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 10.02.2014 00:01, schrieb Dimitry Andric: On 09 Feb 2014, at 16:07, Waitman Gobble uzi...@da3m0n8t3r.com wrote: ... ok, so changing the Makefile for port/devel/glib20 USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 finally solves the problem with graphics/rawtherapee. The program works on my FreeBSD 11.0-CURRENT machine without crashing. (although it's not really a rawtherapee issue, it's related to glib20). So, we can cross another one off clang's list? :-) No we can't. Rawtherapee 4.0.12 is using GCC 4.8 exclusively: - base clang lacks OpenMP support - and OpenMP really speeds up RT if there are multiple processors to distribute load onto - base clang still has the pathological compile time/RAM use issue you filed bugs about when we were discussing Rawtherapee 4.0.11, and GCC 4.6 and 4.7 also crash with internal compiler errors. Since 4.8 works, I forwent filing reports because I did not intend to hunt down all those cases and waive most of the optimizing. If you want to see how clang fares compiling rawtherapee, use a 10.x system, remove the USE_GCC and force OpenMP to off (unless you happen to have an OpenMP-aware clang). signature.asc Description: OpenPGP digital signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi, On Sun, 9 Feb 2014 07:07:00 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote: USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 as you might have expected, this also fixes rawtherapee on 10.0. Erich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 07.02.2014 05:22, schrieb Erich Dollansky: Hi, I just faced the same problem. ... It looks to me that the entry in libmap.conf is not even needed as there is a link in /usr/local/lib anyway. Rawtherapee is a very sensitive program from my point of view. It works after one update and it crashes after the next. It might also be just random. Sorry, but that won't help. Either someone (not me) can debug this, or we'll just not use the port on 11. I have marked the port BROKEN on OSVERSION = 110. If someone wants to use rawtherapee on 11, he'll have to do some digging/debugging; and the port build is still possible by adding TRYBROKEN=yes to the make command line, and possibly WITH_DEBUG=yes on several of the requisites and on rawtherapee itself, or I'll need to collect at least three plausible reports from FreeBSD 11 systems that rawtherapee works there. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 08:52 (UTC+1) schrieb Baptiste Daroussin: On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. I commented out libmap.conf entry, reinstalled devel/libc++ and readded libmap.conf entry. After that, I get the same error, when starting rawtherapee. In a second step I tried to rebuild graphics/rawtherapee with the entry in /etc/libmap.conf active. That also fails with: [..snip..] /bin/mkdir -p /usr/ports/graphics/rawtherapee/work/.build Shared object /usr/local/lib/libc++.so.1 not found, required by cmake *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/rawtherapee *** Error code 1 Rainer Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 08:23 (UTC+1) schrieb Dimitry Andric: On 06 Feb 2014, at 07:48, Rainer Hurling rhur...@gwdg.de wrote: ... I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? No, libc++.so is a linker script, similar to libc.so: $ cat /usr/lib/libc++.so /* $FreeBSD: head/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) Oh, yes. I did not look enough at it, sorry. So no problem here in this place. Thanks, Rainer -Dimitry ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi, I just faced the same problem. On Thu, 06 Feb 2014 10:27:12 +0100 Rainer Hurling rhur...@gwdg.de wrote: Am 06.02.2014 08:52 (UTC+1) schrieb Baptiste Daroussin: On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. I commented out libmap.conf entry, reinstalled devel/libc++ and readded libmap.conf entry. After that, I get the same error, when starting rawtherapee. In a second step I tried to rebuild graphics/rawtherapee with the entry in /etc/libmap.conf active. That also fails with: [..snip..] /bin/mkdir -p /usr/ports/graphics/rawtherapee/work/.build Shared object /usr/local/lib/libc++.so.1 not found, required by cmake *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/rawtherapee *** Error code 1 It looks to me that the entry in libmap.conf is not even needed as there is a link in /usr/local/lib anyway. Rawtherapee is a very sensitive program from my point of view. It works after one update and it crashes after the next. It might also be just random. Erich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 20:46, schrieb Rainer Hurling: Many thanks for the update of graphics/rawtherapee, r342622. This program is really important for photographers. It builds and installs just fine on recent HEAD amd64, but unfortunately it crashes immediately, when started. Rainer, I don't see the crash on FreeBSD 10.0-RELEASE amd64 and 9.2-RELEASE amd64 - those are versions I tried and where I could successfully open a Sony ARW file and click a few UI items. Note sure what 11 changed that it would break. I tried to build rawtherapee and some of its dependencies with WITH_DEBUG=yes and then to have a look with gdb, but with only little luck. Obviously there is a problem with DWARF(?) and many libs without debug symbols? It's rather that the base /usr/bin/gdb cannot deal with the newer debug symbol formats... # gdb rawtherapee [..SNIP..] This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/bin/rawtherapee] [..SNIP..] ...do you have more luck with gdb built from the ports collection (devel/gdb), which is version 7.6.2, as opposed to the base system gdb 6.1.1? Also, if you recompile rawtherapee without the highly aggressive compiler flags, does that help? I saw warnings about undefined behaviour in aggressive loop optimization, not sure if those are the culprit. If they are, we might need to tune down optimization a bit. Thanks. Cheers, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
On 05 Feb 2014, at 20:46, Rainer Hurling rhur...@gwdg.de wrote: Many thanks for the update of graphics/rawtherapee, r342622. This program is really important for photographers. It builds and installs just fine on recent HEAD amd64, but unfortunately it crashes immediately, when started. I tried to build rawtherapee and some of its dependencies with WITH_DEBUG=yes and then to have a look with gdb, but with only little luck. Obviously there is a problem with DWARF(?) and many libs without debug symbols? It looks like you have built the port with gcc 4.8, which defaults to DWARF4 format. Our gdb in base is too old to understand this format, so just install devel/gdb76 instead. # gdb rawtherapee ... #3 0x423aa8f8 in Glib::ConvertError::throw_func () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #4 0x423baa0f in Glib::Error::throw_exception () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #5 0x423c60b4 in Glib::operator () from /usr/local/lib/libglibmm-2.4.so.1 Looks like that operator encountered something it cannot handle, so it throws an exception, and nobody seems to catch it. But more information from a backtrace in gdb 7.6 could possibly help. ... #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) signature.asc Description: OpenPGP digital signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi Matthias,
thanks for answering.
Am 05.02.2014 21:03, schrieb Matthias Andree:
Am 05.02.2014 20:46, schrieb Rainer Hurling:
Many thanks for the update of graphics/rawtherapee, r342622. This
program is really important for photographers.
It builds and installs just fine on recent HEAD amd64, but unfortunately
it crashes immediately, when started.
Rainer,
I don't see the crash on FreeBSD 10.0-RELEASE amd64 and 9.2-RELEASE
amd64 - those are versions I tried and where I could successfully open a
Sony ARW file and click a few UI items. Note sure what 11 changed that
it would break.
I tried to build rawtherapee and some of its dependencies with
WITH_DEBUG=yes and then to have a look with gdb, but with only little
luck. Obviously there is a problem with DWARF(?) and many libs without
debug symbols?
It's rather that the base /usr/bin/gdb cannot deal with the newer debug
symbol formats...
# gdb rawtherapee
[..SNIP..]
This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong
version in compilation unit header (is 4, should be 2) [in module
/usr/local/bin/rawtherapee]
[..SNIP..]
...do you have more luck with gdb built from the ports collection
(devel/gdb), which is version 7.6.2, as opposed to the base system gdb
6.1.1?
Okay, here it comes. RawTherapee from before, with newer gdb:
#gdb762 rawtherapee
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/rawtherapee...done.
(gdb) r
Starting program: /usr/local/bin/rawtherapee
[New LWP 100312]
[New Thread 4ec06400 (LWP 100312)]
Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError
Program received signal SIGABRT, Aborted.
[Switching to Thread 4ec06400 (LWP 100312)]
0x48b847ba in thr_kill () from /lib/libc.so.7
(gdb) bt full
#0 0x48b847ba in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1 0x48c3b029 in abort () from /lib/libc.so.7
No symbol table info available.
#2 0x484d37da in ?? () from /lib/libcxxrt.so.1
No symbol table info available.
#3 0x423aa8f8 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#4 0x423baa0f in Glib::Error::throw_exception(_GError*) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#5 0x423c60b4 in
Glib::operator(std::__1::basic_ostreamwchar_t,
std::__1::char_traitswchar_t , Glib::ustring const) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#6 0x0064fce7 in
Glib::ustring::FormatStream::streamGlib::ustring (this=0x7fffbae0,
value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
No locals.
#7 0x0064f765 in Glib::ustring::formatGlib::ustring, char [9]
(a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
buf = {stream_ =
{std::__1::basic_ostreamwchar_t, std::__1::char_traitswchar_t
= {std::__1::basic_ioswchar_t, std::__1::char_traitswchar_t =
{std::__1::ios_base = {No data fields}, __tie_ = 0x0,
__fill_ = -1}, _vptr.basic_ostream = 0xf853b8 vtable
for std::__1::basic_ostringstreamwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t +24},
__sb_ = {std::__1::basic_streambufwchar_t,
std::__1::char_traitswchar_t = {
_vptr.basic_streambuf = 0xf85490 vtable for
std::__1::basic_stringbufwchar_t, std::__1::char_traitswchar_t,
std::__1::allocatorwchar_t +16, __loc_ = {static none = 0,
static collate = 1, static ctype = 2, static monetary
= 8, static numeric = 16, static time = 32, static messages = 4, static
all = 63, __locale_ = 0x484c0ee0}, __binp_ = 0x0,
__ninp_ = 0x0, __einp_ = 0x0, __bout_ = 0x7fffbb2c
L, __nout_ = 0x7fffbb2c L, __eout_ = 0x7fffbb3c L},
__str_ = {std::__1::__basic_string_commontrue = {No
data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t ::__rep,
std::__1::allocatorwchar_t, 2u = {std::__1::allocatorwchar_t =
{No data fields}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
= 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
__data_ = L'\000' repeats 16 times}, __r =
{__words = {8, 0, 0}, No data fields}, static npos =
18446744073709551615}, __hm_ = 0x7fffbb2c L, __mode_ = 16}}}
#8 0x0064c798 in RTImage::setPaths (opt=...) at
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port regards, Bapt pgpKFNMduTtRB.pgp Description: PGP signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi Rainer,
this is more useful as a backtrace in itself, but I don't know how to
make heads or tails of it; the interesting parts appear to be in frames
#5 (meaning that you might need to reinstall glibmm WITH_DEBUG=yes) and
#8/#9 (where the whole call chain starts).
I can say that rawtherapee starts properly for me on 9.2-RELEASE and
10.0-RELEASE amd64 (the former has packages built from source, the
latter uses binary packages installed with pkg upgrade), even with
aggressive optimization.
Unfortunately, I do not have the time to debug highly complex ports on
any STABLE/UNSTABLE/HEAD tree. My ports work is limited to what I can do
on -RELEASE.
So I propose to
1. first trying the libc++.so mapping that Baptiste Daroussin has
proposed, and if that does not help,
2. hack the Makefile to use only -O for optimization and then see in the
frames #9/#8 if the string passed down is properly initialized, and in
frame #5 what data arrives and why glibmm fails to convert it.
Also make sure that all requisites of rawtherapee are up to date, there
have been many changes to a few of the requisites lately.
Okay, here it comes. RawTherapee from before, with newer gdb:
Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError
Program received signal SIGABRT, Aborted.
...
No symbol table info available.
#3 0x423aa8f8 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#4 0x423baa0f in Glib::Error::throw_exception(_GError*) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#5 0x423c60b4 in
Glib::operator(std::__1::basic_ostreamwchar_t,
std::__1::char_traitswchar_t , Glib::ustring const) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#6 0x0064fce7 in
Glib::ustring::FormatStream::streamGlib::ustring (this=0x7fffbae0,
value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
No locals.
#7 0x0064f765 in Glib::ustring::formatGlib::ustring, char [9]
(a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
buf = {stream_ =
{std::__1::basic_ostreamwchar_t, std::__1::char_traitswchar_t
= {std::__1::basic_ioswchar_t, std::__1::char_traitswchar_t =
{std::__1::ios_base = {No data fields}, __tie_ = 0x0,
__fill_ = -1}, _vptr.basic_ostream = 0xf853b8 vtable
for std::__1::basic_ostringstreamwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t +24},
__sb_ = {std::__1::basic_streambufwchar_t,
std::__1::char_traitswchar_t = {
_vptr.basic_streambuf = 0xf85490 vtable for
std::__1::basic_stringbufwchar_t, std::__1::char_traitswchar_t,
std::__1::allocatorwchar_t +16, __loc_ = {static none = 0,
static collate = 1, static ctype = 2, static monetary
= 8, static numeric = 16, static time = 32, static messages = 4, static
all = 63, __locale_ = 0x484c0ee0}, __binp_ = 0x0,
__ninp_ = 0x0, __einp_ = 0x0, __bout_ = 0x7fffbb2c
L, __nout_ = 0x7fffbb2c L, __eout_ = 0x7fffbb3c L},
__str_ = {std::__1::__basic_string_commontrue = {No
data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t ::__rep,
std::__1::allocatorwchar_t, 2u = {std::__1::allocatorwchar_t =
{No data fields}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
= 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
__data_ = L'\000' repeats 16 times}, __r =
{__words = {8, 0, 0}, No data fields}, static npos =
18446744073709551615}, __hm_ = 0x7fffbb2c L, __mode_ = 16}}}
#8 0x0064c798 in RTImage::setPaths (opt=...) at
/usr/ports/graphics/rawtherapee/work/rawtherapee-4.0.12/rtgui/rtimage.cc:101
configFilename = {static npos = 18446744073709551615, string_ =
{std::__1::__basic_string_commontrue = {No data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringchar,
std::__1::char_traitschar, std::__1::allocatorchar ::__rep,
std::__1::allocatorchar, 2u = {std::__1::allocatorchar = {No
data fields}, __first_ = {{__l = {__cap_ = 0, __size_ = 0, __data_ =
0x0}, __s = {{__size_ = 0 '\000', __lx = 0 '\000'}, __data_ = '\000'
repeats 22 times}, __r = {__words = {0,
0, 0}, No data fields}, static npos =
18446744073709551615}}
keyFile = {Glib::KeyFile = {gobject_ = 0x4ec15d80,
owns_gobject_ = true}, No data fields}
hasKeyFile = true
#9 0x00696aaf in main (argc=1, argv=0x7fffd6d0) at
/usr/ports/graphics/rawtherapee/work/rawtherapee-4.0.12/rtgui/main.cc:239
m = incomplete type
icon_path = {static npos = 18446744073709551615, string_ =
{std::__1::__basic_string_commontrue = {No data fields},
__r_ =
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 07:03 (UTC+1) schrieb Rainer Hurling: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? Thanks for the tip, Rainer regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
On 06 Feb 2014, at 07:48, Rainer Hurling rhur...@gwdg.de wrote: ... I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? No, libc++.so is a linker script, similar to libc.so: $ cat /usr/lib/libc++.so /* $FreeBSD: head/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. Bapt pgpPWuUeEwfNP.pgp Description: PGP signature
