On 02 October, 2017 - Tomaz Canabrava wrote: > On Sun, Oct 1, 2017 at 9:21 PM, Lubomir I. Ivanov <[email protected]> > wrote: > > > On 1 October 2017 at 22:05, Cristian Ionescu-Idbohrn > > <[email protected]> wrote: > > > On Sun, 1 Oct 2017, Dirk Hohndel wrote: > > >> > > >> Can you send a patch for the INSTALL for to capture the right > > >> packages that need to be installed? > > > > > > I don't need to. The packages are already listed in INSTALL: > > > > > > 101: libcrypto++-dev libssl-dev qml-module-qtpositioning > > qml-module-qtlocation > > > 112: libcrypto++-dev libssl-dev qml-module-qtpositioning > > qml-module-qtlocation > > > > > > for both debian and ubuntu. In my case (debian unstable) those > > > packages were removed when I did a major qt5 upgrade. > > > > > > In any case, the point I'm trying to make is subsurface should _not_ > > > segfault because of that. That case should be properly error handled, > > > shouldn't it? > > > > was noted previously and we can try not to crash: > > https://github.com/Subsurface-divelog/subsurface/issues/596 > > > > > > > > The two libraries: > > > > > > /usr/lib/x86_64-linux-gnu/qt5/qml/QtLocation/libdeclarative_location.so > > > /usr/lib/x86_64-linux-gnu/qt5/qml/QtPositioning/ > > libdeclarative_positioning.so > > > > > > are probably loaded at runtime (maybe with dlopen?). The code that > > > does that appears not to do error handling. > > > > > > It also appears the cmake rules don't check either. Shouldn't they? > > > > > > > i don't know if we can do that, but it's great if we can detect > > missing modules at build time and abort the build. > > > > We can. > I'll try to send a patch today.
Can we handle the missing module runtime, in a better way than segfaulting. In my simplified world it would be catching the right exception, and disabling the map view? //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
