Summary: | graphics/shotwell: Segmentation fault | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | tonymaher | ||||
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||
Status: | Closed Overcome By Events | ||||||
Severity: | Affects Only Me | CC: | beastie, cmt, riggs | ||||
Priority: | --- | Keywords: | needs-patch, needs-qa | ||||
Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(cmt) |
||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
tonymaher
2014-12-23 19:58:18 UTC
Maintainer CC'd I'm even sure it did "work for me" as of last week. I'll have a look into the issue once I get back to my own "real" shotwell installation. From the backtrace alone - is it possible you have some mix of gcc/clang compiled libraries? (not that I'm in any way sure that this is the issue, but I have seen similar crashes while experimenting with OpenMP-enabled (gcc-compiled) libraw, when using the wrong mix of options across ports). How do you tell which compiler has been used? I have mostly been using prebuilt packages. The only ones compiled locally were ones that did not have a package. I did try earlier to reinstall/rebuild using portupgrade and some did compile locally (ports more recent than packages) to see if that fixed the problem. It did not. I cannot reproduce your problem with my files on my installation. Can you attach a testcase (some image file triggering the bug)? For reference, I'm using shotwell compiled with gcc, as my libraw has OpenMP support activated. I'm not sure about the default options, but you might want to check if shotwell and/or libraw are linked against libgcc_s.so and possibly libgomp.so (yes, libgomp - the GNU OpenMP library). ldd /usr/local/bin/shotwell | grep libgcc_s.so libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x808f76000) ldd /usr/local/lib/libraw.so.9 | grep libgcc_s.so libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801c4d000) ldd /usr/local/lib/libraw.so.9 | grep libgomp ldd /usr/local/bin/shotwell | grep libgomp Any image causes it to crash. If I try to compile libraw it uses c++ (no openmp defined). Cannot work out hpow to override that. Thanks. Ran make config and selected OpenMP and then did make install. Now it is working fine. So some sort of clang vs gcc issue. (In reply to tonymaher from comment #6) To be clear I just recompiled shotwell with openmp selected. (In reply to tonymaher from comment #7) Ah, now... I completely missed that you have the ancient gcc as a default compiler (I'm on FreeBSD 10.1, so I've got clang since 10BETA or so). So I think it's not a case of "clang vs. gcc" (you would need to switch the default compiler on your own for that, I don't think official packages would be built that way), but it's totally possible that "some update" (there was the huge GNOME-update, including vala, for example) made shotwell or one of it's dependencies trigger a bug in the ancient gcc or it's libraries. I think it might be neccessary to force USE_GCC at least on FreeBSD 9. I'll have to check if there are drawbacks if I set USE_GCC unconditionally. Created attachment 153401 [details]
fix compiler&libs, pet portscout
- fix crash described here (at least I cannot reproduce it anymore in a VM)
- fix build after webkit-gtk3 upgrade (#196707)
- add portscout info (shotwell 0.21 is described as an "unstable pre-release")
This doesn't look right to me. 1) the whole point of using USES=compiler: is to avoid having to use OSVERSION. you have OSVERSION check before setting USES=compiler 2) You use OSVERSION without checking OPSYS. This breaks OPSYS=DragonFly. 3) More DragonFly incompatibility -- DragonFly has libgomp in base and does not have libc++ I would say at the very least do something like: .if ${PORT_OPTIONS:MOPENMP} . if ${OPSYS} == FreeBSD [your stuff] . endif .endif that should be fine for dragonfly since it supports gomp in base. A new upstream version has been committed, see https://svnweb.freebsd.org/changeset/ports/382548 This should fix the reported issue here in the process. |