Created attachment 151602 [details] patch file With the upgrade of webkit-gtk3 to 2.4.8 and USES of 'compiler:c++11-lib', this was one of three ports that I encountered calling for similar patches as used when this occurred for webkit-gtk2. Additionally, if the OPENMP option is selected, libc++.so could not be found. This used to be a dependency of 'www/webkit-gkt3', but it isn't anymore since it USES 'compiler:c++11-lib'. For my FreeBSD 9.3 builds, I changed it to use libstdc++.so instead. As for 10+, I'm not sure which would be the correct way to go, but I added a LIB_DEPENDS for 'libc++.so'.
Maintainer CC'd
finally I got this and the crash reported in #196236 fixed without breaking build or OpenMP for me. Please see patch over there: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153401
Created attachment 154643 [details] new, non-OSVERSION dependent patch Yeah, haven't been on computer much in a long time (and still no timeline on when I'll get my digital pictures processed to share with relatives -- seems digital has made sharing photos take more time now ;) .... hack out lots of rambling on what might be the fix, then have computer lock up, recover comment using Lazarus extension, but then decide on a different solution. .... Decided the solution would be to do the attached. 'compiler:c++11-lib' is wanted because it is what 'www/webkit-gtk3' used, and its use wasn't OSVERSION dependent. Though suspect on FreeBSD 10+ its satisfied by base clang, while on <10 it needs ports gcc. While libraw + OPENMP used "OPENMP_USE= gcc=yes". This would also likely be sufficient here, figure 'compiler:gcc-c++11-lib' would be safest. This USES appears to force use of ports gcc, and have the framework decide on whether libc++ is needed. .... It wasn't an issue before, because before 'www/webkit-gtk3' switched to using 'compiler:c++11-lib' (r376609), it would use 'lang/clang34' and 'devel/libc++' if OSVERSION < 1000019.
Created attachment 154678 [details] fix Makefile ordering You're right, this seems to work. Duh, I was thinking too complicated :) Only to make it really work, the OPENMP_USES-variables have to go before bsd.port.options.mk to take effect. Ready for committer, thanks.
Is attachment 154643 [details] now obsolete?
(In reply to Kubilay Kocak from comment #5) yes, https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154643 is now obsolete - but it looks like I cannot set "obsolete" on other people's patches (or am I missing something?) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154678 is the correct version of that patch.
Created attachment 154835 [details] my corrected patch FWIW, I had intended to upload this corrected patch after discovering the problem in doing a 'poudriere testport' on it. I did another run to check that the fix I had made was right....but there had been enough dependencies updated between runs that it was going to take hours to see the results. Then my computer crashed, and I forgot to check if I had hit submit or not. Can't confirm that things work between OPENMP on or off, as I don't have any FreeBSD 10.x, yet (bad enough that I can't rebuild ports for 9.3 in poudriere in preparation of upgrading poudriere server from 9.2 ;)
okay, thanks. I'll promote this, but the committer needs to build on FreeBSD 10.1
we can obsolete this bug now - there's the next shotwell version out and I just filed the upgrade PR ports/198986 where I integrated all the changes from here.
Obsoleted by bug 198986