Re: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

Am 12.02.2014 07:20, schrieb Erich Dollansky:
> Hi,
> 
> On Wed, 12 Feb 2014 06:49:28 +0100
> Christoph Moench-Tegeder  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: libc++ port's undesired side effects (was: graphics/rawtherapee: r342622 crashes on HEAD)

[Matthias Andree]

Baptiste, Bryan,

we may want to move the port's libc++.so (and requisites) into a
subdirectory so we don't lump it in a ports standard library path. See
below for more, look for your name if pressed for time.


Rainer Hurling wrote earlier today:

> 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.

Rainer,

So there is not a dependency that should be recorded in the port.  It
still is with pkgNG as you show below.

> 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.

Because they use other headers and libraries from the same paths.

> 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.

[Moved here from end of Rainer's message:]
> #ldd /usr/local/bin/darktable | grep c++
>   libc++.so.1 => /usr/local/lib/libc++.so.1 (0x4690e000)

It does not create a dependency in the strict sense.  The port only
states it needs libc++.so.1 (and libcairomm-1.0.so.1 to pick a random
sample, and many others), and it states a run-time linker path extension
(RPATH) tag.

Which actual library file is used by the run-time linker is _not_
recorded in the binary but resolved in the order specified in the
"ld.so" manual page, and according to that search path, it just happens
that /usr/local/lib/libc++.so.1 shadows /usr/lib/libc++.so.1.

Now you found out in your run-time experiment that you are able to
remove /usr/local/lib/libc++.so.1, and you will then find that the same
ldd command as you show below would resolve from /usr/lib/libc++.so.1
instead of /usr/local/lib/libc++.so.1.

And that is the reason why I have not recorded a run-time dependency in
Rawtherapee's Makefile on systems that have libc++ in a default base
install.


Baptiste: We might want to move libc++.so to a subdirectory from
/usr/local/lib so we might detect incompatibilities between base and
port libc++.so sooner.

Possible locations are: /usr/local/lib/c++/v1 to mirror the include file
structure, or /usr/local/c++/v1/lib, and moving headers to
/usr/lcoal/c++/v1/include, to share a common prefix for CPPFLAGS -I
options and LDFLAGS -L options.


>>> #pkg info -r libc++-200683
>>> libc++-200683:
>>> rawtherapee-4.0.12_1
>>> darktable-1.2.3_3

Baptiste, Bryan, and that appears to be an artifact of pkg, and a
(possibly deliberate "regression").  These dependees should not be
listed.  Please abstain from hasty commits to just the libc++, we'll
need to coordinate our changes in proper cadence to avoid bringing lots
of compatibility baggage in, and to avoid breaking the ports that
require the libc++ in some way.

The port explicitly specifies a BUILD_DEPENDS, so we should not have a
run-time dependency.  pkg_add does not report such a bogus dependency.

I think we may want to either change pkg to not record BUILD_DEPENDS, or
if that is not desired, revise the install layout of the libc++ port so
that the port would normally reference /usr/lib/libc++.so if present, to
avoid adding the run-time dependency.


___
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]

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: PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD

[Erich Dollansky]

Hi,

On Wed, 12 Feb 2014 06:49:28 +0100
Christoph Moench-Tegeder  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

[Christoph Moench-Tegeder]

## 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

[Tijl Coosemans]

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

[Matthias Andree]

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

[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++.

> #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

[Rainer Hurling]

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

[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.

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

[Rainer Hurling]

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

[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.

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

[Tijl Coosemans]

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
>

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

[Rainer Hurling]

Am 11.02.2014 10:09 (UTC+1) schrieb Matthias Andree:
> (stripping Cc: list down a bit)
> 
> Am 11.02.2014 09:54, schrieb Rainer Hurling:
> 
>>> *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:*
>>
>> I just tried RawTherapee after rebuilding devel/glib20 with the iconv
>> related patch, and it works flawlessly! Some small test with filters and
>> converting also seem to work.
>>
>> This is on HEAD r261632 amd64. RawTherapee is build with gcc48 and
>> OpenMP support.
>>
>> Once, if there is an official patch in the ports tree, is it recommended
>> to rebuild all dependencies of glib20?
> 
> Unless there will be other changes to glib20 outside the patch, that
> would not be required.  The patch to glib20 does not change its ABI to
> applications (its 'consumers', so to say), so just reinstalling glib20
> so that it uses libiconv rather than libc for iconv*() functions would
> suffice (and on FreeBSD 8.x and 9.x, glib20 always uses libiconv.)
> 
>>> 1. download Koop's patch to glib20 from
>>>
>>>
>>> 2. apply the patch, build and install glib20 with the patch
>>>
>>> 3. try *and report* if that fixes the rawtherapee crashes?
>>
>> Many thanks to not give up with this issue! RawTherapee is a great raw
>> processor for both, amateurs and professionals. And it is one of that
>> great programs, we want to use on different platforms (including Windows).
> 
> Unfortunately the code base is less sound than we would like for a
> portable application.  I've read a few upstream crash issues and RT
> seems a pig to debug.

I just recognized another issue, what I think is not intended.

Newest graphics/rawtherapee installs and uses devel/libc++. This wanted
behaviour is included in the ports Makefile for OpenMP reasons.

As a side effect, other ports with c++ usage also seem to grab
devel/libc++, even if devel/libc++ is not mentioned in the ports
Makefile. You can try this by rebuilding and reinstalling e.g.
graphics/darktable. This leads to

#pkg info -r libc++-200683
libc++-200683:
rawtherapee-4.0.12_1
darktable-1.2.3_3

#ldd /usr/local/bin/darktable | grep c++
libc++.so.1 => /usr/local/lib/libc++.so.1 (0x4690e000)

I don't know, if this is harmless or if this should not happen?

Once again, this is on HEAD r261632 amd64.

Any comments or ideas?

Regards,
Rainer
___
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]

(stripping Cc: list down a bit)

Am 11.02.2014 09:54, schrieb Rainer Hurling:

>> *Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:*
> 
> I just tried RawTherapee after rebuilding devel/glib20 with the iconv
> related patch, and it works flawlessly! Some small test with filters and
> converting also seem to work.
> 
> This is on HEAD r261632 amd64. RawTherapee is build with gcc48 and
> OpenMP support.
> 
> Once, if there is an official patch in the ports tree, is it recommended
> to rebuild all dependencies of glib20?

Unless there will be other changes to glib20 outside the patch, that
would not be required.  The patch to glib20 does not change its ABI to
applications (its 'consumers', so to say), so just reinstalling glib20
so that it uses libiconv rather than libc for iconv*() functions would
suffice (and on FreeBSD 8.x and 9.x, glib20 always uses libiconv.)

>> 1. download Koop's patch to glib20 from
>>
>>
>> 2. apply the patch, build and install glib20 with the patch
>>
>> 3. try *and report* if that fixes the rawtherapee crashes?
> 
> Many thanks to not give up with this issue! RawTherapee is a great raw
> processor for both, amateurs and professionals. And it is one of that
> great programs, we want to use on different platforms (including Windows).

Unfortunately the code base is less sound than we would like for a
portable application.  I've read a few upstream crash issues and RT
seems a pig to debug.

___
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]

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
>
> 
> 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"

PATCH: Re: graphics/rawtherapee: r342622 crashes on HEAD

[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.

*Can everyone who has rawtherapee crash on FreeBSD 10 or 11 please:*

1. download Koop's patch to glib20 from
   

2. apply the patch, build and install glib20 with the patch

3. try *and report* if that fixes the rawtherapee crashes?

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

[Erich Dollansky]

Hi,

On Mon, 10 Feb 2014 10:03:47 +0100
Matthias Andree  wrote:

> Am 10.02.2014 03:40, schrieb Erich Dollansky:
> > 
> > On Sun, 9 Feb 2014 07:07:00 -0800
> > "Waitman Gobble"  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"

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

Am 10.02.2014 03:40, schrieb Erich Dollansky:
> Hi,
> 
> On Sun, 9 Feb 2014 07:07:00 -0800
> "Waitman Gobble"  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

[Erich Dollansky]

Hi,

On Sun, 9 Feb 2014 07:07:00 -0800
"Waitman Gobble"  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

[Matthias Andree]

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

[Matthias Andree]

Am 10.02.2014 00:01, schrieb Dimitry Andric:
> On 09 Feb 2014, at 16:07, Waitman Gobble  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

[Dimitry Andric]

On 09 Feb 2014, at 16:07, Waitman Gobble  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

[Waitman Gobble]

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 
> #include 
> #include 
>
>
>
>
> 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
> 
> 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:
> ...
> 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

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

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 
> > #include 
> > #include 
> >
> >
> >
> >
> > 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
> > 
> > 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

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
> #include 
> #include 
>
>
>
>
> 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
> 
> 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:
> ...
> 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

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

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 
> >>> #include 
> >>> #include 
> >>>
> >>>
> >>>
> >>> 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
> >>> 
> >>> 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:
> >>> ...
> >>> 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  0x

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
>>> #include 
>>> #include 
>>>
>>>
>>>
>>> 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
>>> 
>>> 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:
>>> ...
>>> 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_str

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

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 
> > #include 
> > #include 
> >
> >
> > 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
> > 
> > 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:
> > ...
> > 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::format > (std::__1::ios_base&), std::__1::__iom_t5, double>

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
> #include 
> #include 
>
>
> 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
> 
> 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:
> ...
> 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::format (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
> , 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 

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
> #include 
> #include 
>
>
> 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
> 
> 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:
> ...
> 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::format (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
> , 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 a

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
#include 
#include 

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 
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:
...
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::format(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
, 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

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

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 
#include 
#include 

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 
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:
...
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::format(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
, 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

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

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

[Erich Dollansky]

Hi,

I just faced the same problem.

On Thu, 06 Feb 2014 10:27:12 +0100
Rainer Hurling  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

[Rainer Hurling]

Am 06.02.2014 08:23 (UTC+1) schrieb Dimitry Andric:
> On 06 Feb 2014, at 07:48, Rainer Hurling  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

[Rainer Hurling]

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

[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.

Bapt


pgpPWuUeEwfNP.pgp
Description: PGP signature

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Dimitry Andric]

On 06 Feb 2014, at 07:48, Rainer Hurling  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

[Rainer Hurling]

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

[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"

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

[Matthias Andree]

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_ostream std::__1::char_traits >&, Glib::ustring const&) () from
> /usr/local/lib/libglibmm-2.4.so.1
> No symbol table info available.
> #6  0x0064fce7 in
> Glib::ustring::FormatStream::stream (this=0x7fffbae0,
> value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
> No locals.
> #7  0x0064f765 in Glib::ustring::format
> (a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
> buf = {stream_ =
> { >>
> = { >> =
> { = {}, __tie_ = 0x0,
> __fill_ = -1}, _vptr.basic_ostream = 0xf853b8  for std::__1::basic_ostringstream std::__1::char_traits, std::__1::allocator >+24>},
> __sb_ = { std::__1::char_traits >> = {
> _vptr.basic_streambuf = 0xf85490  std::__1::basic_stringbuf,
> std::__1::allocator >+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_ = {> = { data fields>},
> __r_ =
> { std::__1::char_traits, std::__1::allocator >::__rep,
> std::__1::allocator, 2u>> = {> =
> {}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
> = 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
>   __data_ = L'\000' }, __r =
> {__words = {8, 0, 0}, }, 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_ =
> {> = {},
> __r_ =
> { std::__1::char_traits, std::__1::allocator >::__rep,
> std::__1::allocator, 2u>> = {> = { data fields>}, __first_ = {{__l = {__cap_ = 0, __size_ = 0, __data_ =
> 0x0}, __s = {{__size_ = 0 '\000', __lx = 0 '\000'}, __data_ = '\000'
> }, __r = {__words = {0,
> 0, 0}, }, static npos =
> 18446744073709551615}}
> keyFile = { = {gobject_ = 0x4ec15d80,
> owns_gobject_ = true}, }
> 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 = 
> icon_path = {static npos = 18446744073709551615, string_ =
> {> = {},
> __r_ =
> { std::__1::char_traits, std::__1::allocator >::__rep,
> std::__1::allocator, 2u>> = {> = { data fields>}, __first_ = {{__l = {__cap_ = 49, __size_ = 35, __data_ =
> 0x4fe3d220 "/usr/local/share/rawtherapee/images"}, __s = {{__size_ = 49
> '1', __lx = 49 '1'},
>   __data_ =
> "\000\000\000\000\000\000\000#\000\000\000\000\000\000\000
> \322\343O\000\000\000"}, __r = {__words = {49, 35, 1340330528},  data fields>},
> static npos = 18446744073709551615}}
> rtWindow = 0x1
> defaultIconTheme = {pCppObject_ = 0x4fde90a0}
> settings = {pCppObject_ = 0x0}
> 
> 
>>
>> Also, if you recompile rawtherapee without the highly aggressive
>> compiler flags, does 

Re: graphics/rawtherapee: r342622 crashes on HEAD

[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

regards,
Bapt


pgpKFNMduTtRB.pgp
Description: PGP signature

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Rainer Hurling]

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

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:
...
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_ostream >&, Glib::ustring const&) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#6  0x0064fce7 in
Glib::ustring::FormatStream::stream (this=0x7fffbae0,
value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
No locals.
#7  0x0064f765 in Glib::ustring::format
(a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
buf = {stream_ =
{ >>
= { >> =
{ = {}, __tie_ = 0x0,
__fill_ = -1}, _vptr.basic_ostream = 0xf853b8 , std::__1::allocator >+24>},
__sb_ = { >> = {
_vptr.basic_streambuf = 0xf85490 ,
std::__1::allocator >+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_ = {> = {},
__r_ =
{, std::__1::allocator >::__rep,
std::__1::allocator, 2u>> = {> =
{}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
= 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
  __data_ = L'\000' }, __r =
{__words = {8, 0, 0}, }, 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_ =
{> = {},
__r_ =
{, std::__1::allocator >::__rep,
std::__1::allocator, 2u>> = {> = {}, __first_ = {{__l = {__cap_ = 0, __size_ = 0, __data_ =
0x0}, __s = {{__size_ = 0 '\000', __lx = 0 '\000'}, __data_ = '\000'
}, __r = {__words = {0,
0, 0}, }, static npos =
18446744073709551615}}
keyFile = { = {gobject_ = 0x4ec15d80,
owns_gobject_ = true}, }
hasKeyFile = true
#9  0x00696aaf in main (argc=1, argv=0x7fffd

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

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

[Dimitry Andric]

On 05 Feb 2014, at 20:46, Rainer Hurling  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

[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?

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"

graphics/rawtherapee: r342622 crashes on HEAD

[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.

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?


# 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..]

(gdb) r
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/local/lib/gcc48/libgcc_s.so.1]
[..SNIP..]
[New LWP 101478]
[New Thread 4ec06400 (LWP 101478/rawtherapee)]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/local/lib/gcc48/libgcc_s.so.1]
[..SNIP..]
Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError
Program received signal SIGABRT, Aborted.
[Switching to Thread 4ec06400 (LWP 101478/rawtherapee)]
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 __cxa_rethrow () from /lib/libcxxrt.so.1
No symbol table info available.
#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
No symbol table info available.
#6  0x0064fce7 in ?? ()
No symbol table info available.
#7  0x00fa7c00 in ?? ()
No symbol table info available.
#8  0x7fffbae0 in ?? ()
No symbol table info available.
#9  0x7fffbc00 in ?? ()
No symbol table info available.
#10 0x0064f765 in ?? ()
No symbol table info available.
#11 0x7fffbb00 in ?? ()
No symbol table info available.
#12 0x00b8f988 in ?? ()
No symbol table info available.
#13 0x00fa7c00 in ?? ()
No symbol table info available.
#14 0x7fffbd70 in ?? ()
No symbol table info available.
#15 0x00f853b8 in ?? ()
No symbol table info available.
#16 0x00f85490 in ?? ()
No symbol table info available.
#17 0x484c0ee0 in std::__1::locale::id::__next_id () from
/usr/local/lib/libc++.so.1
No symbol table info available.
#18 0x in ?? ()
No symbol table info available.


I know, that this output is only of little help. But I could need some
advise what to do next to get more info.

Any help is really appreciated. Thanks in advance,
Rainer Hurling
___
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"