Re: crash in QMLManager destructor
On Monday, 8 January 2024 18:35:56 -03 Berthold Stoeger wrote: > > Thiago, is that something that makes sense to you? > > > > > > > > here's the disassembled code and yes, it does call terminate... > > Does it? At least not directly as far as I can see. I reckon this is the > exception handler? Quite right, there's no branch instruction arriving there. So it could only be reached via stack unwinding due to an exception being thrown. I don't know Objective C or C++ at all so I can't tell for sure why dealloc would fail. The most likely condition is that the object has become corrupt, probably due to a buffer overflow somewhere or it's a double-free. The object itself appears to be a single 64-bit word in size (probably a pointer). Searching for "objective c dealloc exception" has as first result "don't use dealloc; use release"[1]. I also don't know why Clang inserted that __clang_call_terminate( here. The stack unwinding mechanism should have done that, not the IosShare destructor. In that case, the runtime usually prints the name of the exception that was thrown. Maybe building in ASan mode and running will provide some clue. [1] https://stackoverflow.com/questions/559295/difference-between-release-and-dealloc-in-objective-c > > 0070 : > > 70: a9be4ff4 stp x20, x19, [sp, #-32]! > > 74: a9017bfd stp x29, x30, [sp, #16] > > 78: 910043fd add x29, sp, #16 > > 7c: aa0003f3 mov x19, x0 > > 80: f940 ldr x0, [x0] > > 84: 9400 bl 0x84 > > 0084: ARM64_RELOC_BRANCH26 > > _objc_msgSend$dealloc > > 88: aa1303e0 mov x0, x19 > > 8c: a9417bfd ldp x29, x30, [sp, #16] > > 90: a8c24ff4 ldp x20, x19, [sp], #32 > > 94: d65f03c0 ret > > 98: 9400 bl 0x98 > > 0098: ARM64_RELOC_BRANCH26 > > ___clang_call_terminate -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: crash in QMLManager destructor
On Monday, 8 January 2024 14:10:45 -03 Dirk Hohndel via subsurface wrote: > 7 libc++abi.dylib 0x0001f7aa99c8 std::terminate() > + 56 (cxa_handlers.cpp:88) 8 Subsurface-mobile > 0x00010027589c QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608) The fact that it's spelt "QML" in all caps in the class name led me to find this file in Subsurface's sources. Line 608 is the closing bracket of the destructor, which definitely raises a WTF question: why is it calling std::terminate()? Since there's nothing in the source code for that to call it directly, that implies it's debugging or hardening code inserted by the compiler itself. As it's happening on the closing brace, it's probably QMLManager trying to destroy one of its member variables. The one thing that comes to mind is an exception. Throwing in destructors is really frowned upon (you can't fail to clean up) and by default all destructors are noexcept, so trying to throw from them causes an immediate std::terminate(). If this is the case, then the question is: what is throwing? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mac OS crash report
On Monday, 21 August 2023 17:52:36 PDT MAX ERENBERG via subsurface wrote: > VM Region Info: 0x58 is not in any region. Bytes before following region: > 140737487097768 > 0 QtCore 0x10b61bdaa > QCoreApplication::notifyInternal2(QObject*, QEvent*) + 138 > 1 QtCore0x10b7a7a01 QTimerInfoList::activateTimers() + 961 This is a null-pointer dereference activating a timer. The crash is 0x58 past the null pointer. Comparing to my local build and assuming the structures in question haven't changed sizes between those two versions, offset 0x58 shows up here: QObjectPrivate *d = receiver->d_func(); QThreadData *threadData = d->threadData.loadAcquire(); d->threadData is 0x58 bytes into the QObjectPrivate object, which indicates that d is the null variable. This is of course not supposed to happen: this receiver object must be a dangling pointer. The problem is that the receiver is coming from QTimerInfoList, so it's not the application's fault. Unless it deleted the object from another thread, but I don't see any of the threads as being the likely culprit and if this happened, there should be a warning. I have a vague memory of a bug report like this, but I can't recall the details. Searching for QTimerInfoList::activateTimers() doesn't find anything meaningful. What I do remember is that this function has some convoluted code to deal with reentrancy in the same thread, which turned up in a recent refactoring but has unfortunately has gone nowhere. I'm not convinced the current code works. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Does BLE scanning / downloading work on Mac OS X 13 for anyone else? (It doesn't for me unless I use the QT6 build)
On Tuesday, 7 March 2023 11:09:32 PST Ryan Gardner via subsurface wrote: > Interestingly, an older QT6 experimental build *does* show all the many BLE > devices scattered around my house (including the dive computer I'm scanning > for) A QT5 build from the same day as the QT6 test build does not work. There are 55 fixes to the QtBluetooth Darwin backend since 5.15. I see a few "Pick-to: 5.15" to indicate the fix should be picked to the 5.15 branch, but I don't see those commits in the 5.15 at all. Looks like there's a major refactoring that happened early in 6.x time so those cherry-picks failed and were abandoned. That major refactoring is probably the reason why it's working now on Qt 6. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: testprofile on i686
On Wednesday, 1 December 2021 14:21:28 PST Linus Torvalds via subsurface wrote: > I'm not seeing what's going on, but it smells like some instability in > the calculations rather than some extra non-ieee precision of the > i387. An easy way to verify if it is the 387 extra precision is to remove it: add -msse2 -mfpmath=sse to your C/C++ build flags throughout Subsurface and unit test builds and see of the problem disappears. BTW, Qt by default builds itself with those two flags on i386. Since no one has complained that Subsurface doesn't run on their 20+-year-old computer, we could turn it on for Subsurface too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: testprofile on i686
On Sunday, 28 November 2021 08:50:04 PST Linus Torvalds via subsurface wrote: > > I am trying to package version 5.0.5 for void linux. The build seems to > > pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on > > i686 on the testprofile. Does anyone know why this might be happening > > specifically for this architecture? > > At a guess, it's some floating point rounding issue or similar, and a > failure of the test itself rather than the binary. That would explain why it fails on i686 but nowhere else: x87 floating point, which keeps extra precision between operations that the other ones don't. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: WebKit -> WebEngine
On Sunday, 31 October 2021 10:23:05 PDT Lubomir I. Ivanov via subsurface wrote: > >> Visual Studio 2017 version 15.8 or later, or clang-cl version 8 or later > > they seem to support clang now as well. Please note that clang-cl is not clang. It's the clang front end that is compatible with the MSVC cl syntax and produces MSVC-compatible binaries. I really don't understand what is required to get either clang or GCC to build Chromium. It's not supported because Google doesn't support it, but they are moving towards Clang more and more, so there's a good chance it might "just work" some day, or at least with some effort. After all, the other platforms build with Clang, so it can't be more than some Windows-specific files. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Assistance cross-building Windows target
On Friday, 29 October 2021 03:58:03 PDT Steven Morlock via subsurface wrote: > Howdy, > I have been trying to unsuccessfully follow guidance on how to cross-build > the Windows client. I am running on a OSBoxes.org Ubuntu 21.04 virtual > machine. I have followed as best I could the instructions in > 'subsurface/INSTALL' and > 'subsurface/packaging/windows/mxe-based-build.sh'. Could someone please > review the enclosed 'winbuild.log' and suggest where I may have gone wrong. > Thanks,Steve Hello Steve statsview.h:187:21: error: missing template arguments before '(' token return ChartItemPtr(new T(*this, std::forward(args)...)); "missing template arguments" indicates the code is using template parameter deduction, which is a C++17 feature. statscolors.h:8:46: error: 'backgroundColor' declared as an 'inline' variable inline const QColor backgroundColor(Qt::white); inline variables are a C++17 feature too. barseries.cpp:93:14: error: expected unqualified-id before '[' token for (auto &[dives, label]: item.items) { ^ And this is the syntax for structured bindings, another C++17 feature. Looks like your issue is that Subsurface is not being compiled as C++17. That means your compiler is old. Whether adding the "-std=c++17" / "-std=gnu++17" option would help you or not, I don't know. Recommendation: upgrade your MinGW's GCC. PS: looks like Subsurface is using more C++17 features than my own code! -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Apple Silicone
On Sunday, 24 October 2021 18:35:14 PDT Thiago Macieira via subsurface wrote: > > Any pointers, Thiago? > > There was some discussion about only QtPositioning being available... not > sure. I didn't pay attention. I did a quick check to see if the qtlocation > repository was tagged with 6.2 but didn't check *what* it installs. I don't > keep a full build of Qt in my laptop, that's what workstations wit lots of > cores are for :) > > Can you try QT += positioning to see if that helps and replacing the > #includes? Yep, the module is only QtPositioning: $ ls -ld include/Qt{Positioning,Location} ls: cannot access 'include/QtLocation': No such file or directory drwxr-xr-x 3 tjmaciei tjmaciei 4096 Sep 30 00:50 include/QtPositioning $ ls mkspecs/modules/qt_lib_{positioning,location}.pri ls: cannot access 'mkspecs/modules/qt_lib_location.pri': No such file or directory mkspecs/modules/qt_lib_positioning.pri Here are the classes it contains: $ ls -1 include/QtPositioning 6.3.0 QGeoAddress qgeoaddress.h QGeoAreaMonitorInfo qgeoareamonitorinfo.h QGeoAreaMonitorSource qgeoareamonitorsource.h QGeoCircle qgeocircle.h QGeoCoordinate qgeocoordinate.h QGeoLocation qgeolocation.h QGeoPath qgeopath.h QGeoPolygon qgeopolygon.h QGeoPositionInfo qgeopositioninfo.h QGeoPositionInfoSource QGeoPositionInfoSourceFactory qgeopositioninfosourcefactory.h qgeopositioninfosource.h QGeoRectangle qgeorectangle.h QGeoSatelliteInfo qgeosatelliteinfo.h QGeoSatelliteInfoSource qgeosatelliteinfosource.h QGeoShape qgeoshape.h QNmeaPositionInfoSource qnmeapositioninfosource.h QNmeaSatelliteInfoSource qnmeasatelliteinfosource.h qpositioningglobal.h QtPositioning qtpositioning-config.h QtPositioningDepends QtPositioningVersion qtpositioningversion.h Is this enough for Subsurface needs? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Apple Silicone
On Sunday, 24 October 2021 17:12:04 PDT Dirk Hohndel wrote: > [hohndel@fedora build]$ qmake6 ../googlemaps.pro > Project ERROR: Unknown module(s) in QT: location > > So at least qmake6 doesn't appear to know how to build against Qt Location. Hmm... the "qt_lib_location.pri" file must be missing. I'll take a look tomorrow. > Interestingly, when I go to https://doc.qt.io/qt-6/qtmodules.html > <https://doc.qt.io/qt-6/qtmodules.html> - it doesn't list Qt Location... So > maybe it's only "sort of" there? Or maybe I'm supposed to use it > differently? > Oh, and then using > dnf repoquery -l qt6-qtlocation-devel > shows that this package does, indeed, only contain QtPositioning, but not > QtLocation > > Trying to find anything on this topic via Google has been not very > successful. > > Any pointers, Thiago? There was some discussion about only QtPositioning being available... not sure. I didn't pay attention. I did a quick check to see if the qtlocation repository was tagged with 6.2 but didn't check *what* it installs. I don't keep a full build of Qt in my laptop, that's what workstations wit lots of cores are for :) Can you try QT += positioning to see if that helps and replacing the #includes? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Apple Silicone
On Friday, 22 October 2021 16:52:06 PDT Dirk Hohndel via subsurface wrote: > Some more messing around with Qt 6... we're not only losing QtWebKit - > there's also no Qt Location and no Qt Positioning. Which means no map > module that we can use. Those were missing in 6.0 and 6.1, but qtlocation is back in 6.2. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Apple Silicone
On Friday, 22 October 2021 10:34:08 PDT Dirk Hohndel via subsurface wrote: > I haven't followed this closely enough to see if the Linux distros are > including these patches in their versions, though. They are, at least the ones that follow KDE somewhat closely. https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/sources https://build.opensuse.org/package/show/openSUSE:Factory/libqt5-qtbase https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/ PKGBUILD#L31-L33 etc. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Windows crash
On Tuesday, 30 March 2021 08:30:31 PDT Dirk Hohndel via subsurface wrote: > I wonder why I didn't find this with Valgrind. Given that my professional > software developer career started writing a memory debugger 27 years ago... > I find Valgrind frustratingly inconsistent to use. > > /D Try ASan (-fsanitize=address). Compiling only the executable and not the libraries (especially Qt) with ASan works most of the time, but if you need more info you may need to enable that for Qt too. I find that Valgrind and ASan are complementary and find things the other don't. Valgrind is especially useful when you don't want to recompile. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: libqtgeoservices_googlemaps.so: undefined symbol: _ZN7QGeoMap25fitViewportToGeoRectangleERK13QGeoRectangle
On Thursday, 1 October 2020 01:05:10 PDT Cristian Ionescu-Idbohrn via subsurface wrote: > libqtgeoservices_googlemaps.so: undefined symbol: > _ZN7QGeoMap25fitViewportToGeoRectangleERK13QGeoRectangle)" This is a private symbol in QtLocation that changed between 5.12 and 5.13.0. See https://github.com/qt/qtlocation/commit/ 56e07f78579196fc33580ca5f20073a156b0e2dd The symbol your plugin is looking up is the old one. That means you compiled the plugin against an old Qt (probably accidentally). Recommendation: remove the development packages of Qt that were installed system-wide. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Windows && sqlite?
On Tuesday, 22 September 2020 11:58:04 PDT Dirk Hohndel via subsurface wrote: > > I suspect that parsing the samples fails, and that sql query might be > > something that the version of libsqlite on windows cannot handle... > We use libsqlite 3.32.2 on Windows. > I always wonder if this is a line end issue or something else where the > different character set conversions bite us...? The sqlite file format should be the same. It's binary, so line endings shouldn't be an issue. Only if the lines with CRLF are loaded into the database itself... You can copy the file onto a Linux and use /usr/bin/sqlite to see if it can read. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt version on OpenSuse
On Monday, 20 July 2020 05:55:12 PDT Robert Helling via subsurface wrote: > Hi, > > got a question from a user: He is on OpenSuse Tumbleweed which apparently > comes with Qt 5.15 while the Subsurface package apparently (I didn’t check > any of this) requires 5.13. Is there anything I can tell him besides using > the AppImage? There shouldn't be a problem. Is he experiencing a problem? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: renaming the default branch to 'main'
On Monday, 15 June 2020 13:01:04 PDT Dirk Hohndel via subsurface wrote: > I am at this point working through the steps it will take to rename our > default branch to be 'main Just don't call it MAIN. That's too CVS-y. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Build issues
On Saturday, 4 January 2020 12:31:53 -03 Robert.Helling wrote: > find Subsurface-mobile.app/ |grep dylib$|xargs -n1 otool -L > > here: https://neu.atdotde.de/~robert/ot.out > > Maybe you can spot something odd. Ok, that will catch plugins (as they are .dylib), but not the libraries themselves. Those have a plain, undecorated name like "QtCore". > + '[' '' = 1 ']' > + (( i++ )) > + (( i < 1 )) > > [BTW: What is this?] That's sh -x output, which is showing things after expansion. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Build issues
On Friday, 3 January 2020 21:33:09 -03 Robert Helling wrote: > > objc[85638]: Class > > QT_ROOT_LEVEL_POOL__THESE_OBJECTS_WILL_BE_RELEASED_WHEN_QAPP_GOES_OUT_OF_ > > SCOPE is implemented in both > > /Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore > > (0x1025390e0) and > > /Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Conte > > nts/Frameworks/QtCore.framework/Versions/5/QtCore (0x1078750e0). One of > > the two will be used. Which one is undefined. This looks like an incomplete deployment: some binary resources inside the bundle still point to the original files from the Qt SDK, not the bundled copy of the Qt frameworks. If you use otool -L on each of the binaries inside, can you find out which one still points to that "clang_64" build? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: QT 5.13 on Windows/MXE
On Monday, 2 September 2019 02:23:09 PDT Paul Buxton wrote: > I think it might be because we are trying to access the selected product > before it has been populated, but my Qt-fu is not strong enough to be > certain yet, and the latest MXE doesn't support building Debug-and-Release > for the QT libraries so it isn't clear exactly where the exception is being > generated. You shouldn't need a debug-and-release build to debug. You can do it the Unix way and build an unsuffixed library with debug symbols and without optimisation. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Large negative pressures
On Wednesday, 7 August 2019 10:19:01 PDT Linus Torvalds wrote: > Again, truncation of long to int isn't undefined behavior or overflow. > It's just a value truncation. Strictly speaking, it's defined only if the result fits. Otherwise, the C standard says it's implementation defined what happens. On all modern machines, it just truncates, no warning. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Large negative pressures
On Wednesday, 7 August 2019 09:31:35 PDT Linus Torvalds wrote: > > 2) Make pressure_t (and related variable) int64_t, > > Absolutely not. See above. That would be entirely crazy. Unless you want to use Subsurface to calculate a dive into the core of the Sun (pressure there is estimated at around 250 gigabars). That would overflow the puny int32_t. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: .dev domain
On Thursday, 28 February 2019 18:31:36 PST Dirk Hohndel wrote: > Eventually (when I find the time), I think I'll migrate this mailing list to > be "de...@subsurface.dev <mailto:de...@subsurface.dev>" ... d...@subsurface.dev? subsurface@subsurface.dev? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.12 and Android arm64 build
On Wednesday, 14 November 2018 14:03:54 PST Dirk Hohndel wrote: > Will there be an Android Qt 5.12 built with clang? I don't know if it will be pre-built as such, but Clang support is now present in 5.12. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.12 and Android arm64 build
On Wednesday, 14 November 2018 13:28:04 PST Jan Mulder wrote: > With Qt 5.12 coming soon (end this month), I gave the beta #4 a try > today. My focus was on the cross build of Subsurface-mobile for Android. > Obviously, I ran in some problems, but nothing that seems mayor. One > weird thing I could not solve up to now is an undefined reference from > the linker (QtAndroid::runOnAndroidThread); a construct to set the color > of the header and footer to our liking. That sounds like a mix of two Qt versions, since runOnAndroidThread is defined in qjnihelpers.cpp, inside QtCore, without any #if. That is, you're compiling against 5.12, but linking (or running) against 5.11. Check your environment. > With Qt 5.12 also a build for arm64 architecture becomes feasible. And I > succeeded in a running arm64 app on my device. Also here, relatively > straightforward (in hindsight). This requires a newer API that the > currently used 16. I used API 21 (corresponding to Android 5.0). Note that this will make use of Clang to build, instead of GCC of the older SDKs. Clang produces much larger binaries, even at extreme size optimisation (-Oz). > So, my question for Dirk: interested in set of patches for all this? > Obviously, no hurry here, as 5.12 is still beta. I between I might take > a look into clang instead of gcc for the mobile app, as Android had > moved away from gcc, and support will end someday. The first -rc is expected next week and these days it means any RC could be the final release one week later, if nothing major is found. If you have issues, please report them so we decide whether the RC is good or not. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: erreur d'importation
On Friday, 12 October 2018 02:56:26 PDT jean-yves coppin wrote: > bonjour, > > > je rencontre ce problème sur mon Galileo Sol full de chez UWATEC depuis le > changement de version 4.8.3. Inline translation: I am facing this problem on my Galileo Sol Full from UWATEC after the change of version (upgraded, I guess) 4.8.3 > j'ai mème essayé de revenir sur l'ancienne version rien a faire I have even tried to go back to the old version -- nothing happened. > subsurface ne veut plus m’importer mais plongée Subsurface does not want to import my dives any more. > il n'y a pas eu enregistrement de fichier subsurface.bin There haven't been any modifications to the file subsurface.bin. > j’espère que vous trouverez le problème I hope you'll find this problem. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: libdc, libzip, Mac and Android updates
On Sunday, 5 August 2018 16:01:52 PDT Dirk Hohndel wrote: > b) this brings me to the second thing I figured out: building a working APK > against Qt 5.11.1. You may remember that I had problems with > androiddeployqt not managing to package our APK because a dependency for > one of the Qt plugins was unmet. After lots of googling I pieced together > enough information to realize that the problem is in qt-android-cmake. I > sent a PR to that project and in the meantime switched Subsurface to use my > fork of this that actually tells androiddeployqt to scan the QML modules as > well for dependencies. Thiago, I thought you might be interested in that > part. Do you have a link? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Friday, 13 July 2018 21:32:10 PDT Lubomir I. Ivanov wrote: > > rm -rf qmake > > cmd \ /c config.status > > > > If you're in a regular DOS prompt, probably > > > > rd /s /q qmake > > config.status BTW those config.status.bat are just: configure -redo Usually, on Windows you want to run configure.bat, but if you've been using the sh script and it works for you, you can do that too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Friday, 13 July 2018 21:21:32 PDT Lubomir I. Ivanov wrote: > building qt on windows with mingw (can't look at the version number right > now). > > i was getting a compiler error somewhere in the qmake source > (something about a duplicate "escape path" method), when building the > 5.11 branch of qtbase. > cleaning object code didn't help. to solve this, i removed the qtbase > submodule completely, initialized it again but this time built the > 5.10 branch. qmake is special because it's not built with qmake (circular dependency). So its Makefile is much simpler and is not as complete. When I have such an issue, I do: rm -rf qmake cmd \ /c config.status If you're in a regular DOS prompt, probably rd /s /q qmake config.status -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: MXE with Qt5.11.1 and missing map
On Tuesday, 10 July 2018 18:08:08 PDT Thiago Macieira wrote: > I haven't looked at he macdeployqt tool in a few years, but it shouldn't be > too difficult to fix it. Assuming the other two have copy/pasted code, the > fix should be ported easily too. Quick inspection of the source code shows that it *meant* to deploy the plugins' dependencies. I'm going to try and create a simple testcase to see what happens. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: MXE with Qt5.11.1 and missing map
On Tuesday, 10 July 2018 15:28:43 PDT Dirk Hohndel wrote: > > But they don't recheck after #3 if any plugins require libraries the > > application doesn't link to. This could be worked around by explicitly > > linking to the new library -- except that library has no public symbols > > to require, so many linkers will just drop it as unnecessary. > > So the problem becomes... how do we work around that. Just force the library > to be part of the package... is that the way to go? It's what I did for > macOS and I think I know how to do that win Windows (but haven't tried, > yet). With Android I still haven't figured out how to do that... That sounds like a decent workaround, until the deploy tools get fixed. I haven't looked at he macdeployqt tool in a few years, but it shouldn't be too difficult to fix it. Assuming the other two have copy/pasted code, the fix should be ported easily too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: MXE with Qt5.11.1 and missing map
On Monday, 9 July 2018 23:31:22 PDT Dirk Hohndel wrote: > And the same thing is preventing the Qt 5.11 based Android app from working. > There is some other component or library that we need to select in cmake - > but I can't figure out what the right keyword might be. On Android it's lib > declarative_positioning.so that isn't packaged and that one isn't packaged > because its dependency libQt5PositioningQuick.so is missing. > > That sound awfully familiar, doesn't it? Yeah. My guess is that the deploy applications actually all share the same history and have the same bug. They work like this (my theory): 1) check which libraries the application links to 2) adds regular (non-QML) plugins associated with that library 3) check what QML imports (including plugins) are needed But they don't recheck after #3 if any plugins require libraries the application doesn't link to. This could be worked around by explicitly linking to the new library -- except that library has no public symbols to require, so many linkers will just drop it as unnecessary. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: QMetaObject::invokeMethod
On Saturday, 7 July 2018 08:37:40 PDT Robert Helling wrote: > Hi, > > I am trying to understand some code that contains invocations of > > QMetaObject::invokeMethod > > I admit I not a C++ person in any sense so could somebody please explain why > one would use such a thing? Berthold, I guess you introduced these. In > particular since the Qt documentation says about QMetaObject Usually, that function is used with Qt::QueuedConnection, which instead of calling the method indicated right now, it posts an event to the event queue with the arguments you supply. When the event loop gets to that event, the method you listed gets finally called. Another way of doing the same is by using QTimer::singleShot() with a lambda that carries your parameters. But this wasn't available before Qt 5.4, so there's a lot of code (and muscle memory) using invokeMethod(). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Opensuse Tumbleweed
On Wednesday, 20 June 2018 13:53:03 PDT Dietrich Meyer wrote: > Here is another backtrace, running subsurface 4.7.8-372 on Tumbleweed, not > sure if this can give any more clues... Sorry, it's exactly the same: > #9 0x7fd01de07127 in QPainter::begin(QPaintDevice*) () at /usr/lib64/ > libQt5Gui.so.5 > #10 0x7fd01ec586ce in () at /usr/lib64/libQt5Widgets.so.5 > #11 0x7fd01ec58b4c in QHeaderView::mousePressEvent(QMouseEvent*) () at / > usr/lib64/libQt5Widgets.so.5 -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Opensuse Tumbleweed
On Wednesday, 20 June 2018 12:35:45 PDT Martin Gysel wrote: > I get the following backtrace: > > QPainter::begin: Paint device returned engine == 0, type: 2 Thanks Martin. I don't see anything in the backtrace belonging to Subsurface, so this appears to be a regular Qt regression. Turns out there were a lot of changes to QHeaderView earlier this year, so one of the must be at fault. I can't spot which one just by looking though. To help constrain the search, do you know if this warning was printed with Qt 5.10 too? > #3 0x72724f74 in QPainter::begin(QPaintDevice*) () from > /usr/lib64/libQt5Gui.so.5 > #4 0x73551777 in () from /usr/lib64/libQt5Widgets.so.5 > #5 0x73551c0c in QHeaderView::mousePressEvent(QMouseEvent*) () > from /usr/lib64/libQt5Widgets.so.5 I'm trying to guess which frame is that ??, but it's not clear what it is. My first guess was QHeaderViewPrivate::setupSectionIndicator, which does have a QPainter, but that function is painting on a QPixmap and that wouldn't have printed the warning. But that leaves me out of options. Can you install the debug symbols for the library? zypper in libQt5Gui5-debuginfo That should resolve the ?? to something useful, and possibly also give us line numbers. PS: I'm experimenting with an optimised build of Qt5 that you can find at https://build.opensuse.org/package/show/ home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface on Opensuse Tumbleweed
On Wednesday, 20 June 2018 07:23:27 PDT guillaume.gar...@free.fr wrote: > If I click the dive number it is fine. Otherwise, I get a blank area with > the following messages in console: QPainter::begin: Paint device returned > engine == 0, type: 2 > QPainter::setFont: Painter not active > QPainter::setOpacity: Painter not active > QPainter::end: Painter not active, aborted Can you run with QT_FATAL_WARNINGS=1 and once Subsurface aborts, get the backtrace from these warnings? If these are not the first warnings printed by Subsurface, increase the number 1 to be the number of warnings until that "QPainter::begin". -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sunday, 10 June 2018 01:59:37 CEST Linus Torvalds wrote: > Your debug log doesn't actually have the IO that is done. That seems > to be a Qt issue. We ask for debug output, and some versions of Qt > will give that: > > QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* > = true")); > > and others will apparently just ignore it. Ubuntu installs a global file that overrides. It's up to the user to configure what output they want to see, not the application. The above line needs to be set by the user in the QT_LOGGING_RULES environment variable. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 32-bit Qt
On Thursday, 7 June 2018 03:12:10 PDT Willem Ferguson wrote: > My travel computer is a small laptop with an Atom CPU, running 32-bit > Ubuntu. It looks like Qt5.5. is the last 32-bit version available, since > I cannot find a Qt5.10 32-bit version. Is this correct? Qt 5.10 continues to support 32-bit. You just won't find a binary for download from qt.io for it. You'll have to compile from source, or use the one from your Linux distribution. If you choose the latter, you'll need to make sure it can install the necessary private headers. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with Qt-5.11.0
On Wednesday, 23 May 2018 05:08:58 -03 Gaetan Bisson wrote: > Any ideas how to debug this? Can you valgrind? Without debug symbols in Qt it may be a little difficult to make sense of what we're seeing, but it might help. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Qt 5.11 released -- QSettings can't save on Android
You may want to wait for 5.11.1 or apply the fix[1]. The reason is we're using O_TMPFILE for temporary files now, but the solution to materialise the file suggested in the man page[2] char path[PATH_MAX]; fd = open("/path/to/dir", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR); /* File I/O on 'fd'... */ snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file", AT_SYMLINK_FOLLOW); fails because Android security permissions block the link(2) and linkat(2) system calls. Since you can't have nice things on Android, I've disabled the O_TMPFILE support as well as the rename-overwrite-race-prevention one (renameat(2) system call also blocked and can't use link(2)). statx(2) is also blocked, so you can't get file birth times either. [1] http://code.qt.io/cgit/qt/qtbase.git/commit/? id=f86fbc45667528ac9a496d1476bd139f26b3b5bc [2] http://man7.org/linux/man-pages/man2/open.2.html -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Ubuntu bionic appears to have removed the QtLocation private headers
On Monday, 30 April 2018 08:49:19 PDT Lubomir I. Ivanov wrote: > > What was the package with the Qt private headers? I could just add that > > for > > 18.04 in our Launchpad repo... Should do the trick. > > AFAIK one of the problems was that there are simply no packages for > some of the Qt private headers in Ubuntu (intentionally). > this is why we added this solution to pull private headers: > https://github.com/Subsurface-divelog/subsurface/blob/master/scripts/build.s > h#L148 Right. I also asked on Debian and the answer was that they don't provide private headers unless they are actually required by something else that they also build (like other Qt modules). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Formatting Dive tags string
On Thursday, 5 April 2018 10:32:37 PDT Berthold Stoeger wrote: > Hi, > > On Donnerstag, 5. April 2018 19:28:28 CEST Thiago Macieira wrote: > > On Thursday, 5 April 2018 10:25:37 PDT Berthold Stoeger wrote: > > > It's fine as it is, since all C-strings are supposed to be UTF-8 > > > encoded. > > > The only use I see for fromLatin1() et al. would be importing data from > > > an > > > external source that is not UTF-8. > > > > If it's US-ASCII, it is valid UTF-8, but QString::fromLatin1 is slightly > > faster. > > I don't understand your point. Do you suggest limiting dive-tags to > US-ASCII? I'm stuck on "tag". To me that indicates an identifier, like a Git tag. But that's apparently not what you're using it for. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Formatting Dive tags string
On Thursday, 5 April 2018 10:25:37 PDT Berthold Stoeger wrote: > It's fine as it is, since all C-strings are supposed to be UTF-8 encoded. > The only use I see for fromLatin1() et al. would be importing data from an > external source that is not UTF-8. If it's US-ASCII, it is valid UTF-8, but QString::fromLatin1 is slightly faster. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Cloud server
On Sunday, 1 April 2018 11:55:34 PDT Dirk Hohndel wrote: > I know added another 30GB of storage, hopefully that will last for a while "30 GB will be enough for everyone" ? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Formatting Dive tags string
On Wednesday, 4 April 2018 02:55:22 PDT Berthold Stoeger wrote: > char *s = taglist_get_tagstring(...); > QString tags(s); > free(s); One minor note: this decodes the string as UTF-8. If your string is Latin1 or plain US-ASCII, you should use QString::fromLatin1 or QLatin1String (same thing in this context). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Trouble in Qt-land
On Sunday, 25 March 2018 22:26:39 CST Willem Ferguson wrote: > Pointing to a problem somewhere deep in Qt-land. I think the first > obvious question is why is Qt 5.10.1 not used, but Qt 5.5.1? Probably a matter of setting LD_LIBRARY_PATH to point to the 5.10.1. This should have been dealt with by CMake by creating the necessary RPATH in the Subsurface executable, though... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Roll our own qUtf8Printable()?
On domingo, 25 de fevereiro de 2018 17:13:11 PST Thiago Macieira wrote: > But there's another option, which is to avoid a copy of the QString if the > input is already a QString. Let me try a few variations of possible > solutions and compile Qt to see what happens. > > I'll BRB. Change to Qt: https://codereview.qt-project.org/221331 Here's the implementation details: https://godbolt.org/g/voLGhQ As you can see from the assembly output, it does not create a copy anymore, but does work for any and all types convertible to QString (including QString itself). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Roll our own qUtf8Printable()?
On domingo, 25 de fevereiro de 2018 14:34:28 PST Berthold Stoeger wrote: > I think the compiler can't optimize the copy away, because QString doesn't > copy the string, but does reference counting. I'm not sure if it is allowed > to throw away the side effects of the ref()/deref() calls? This does some > atomic stuff, so is obviously a bit hairy. I'm not sure it can. Because the variable is an atomic, the compiler may conclude it cannot remove a pair of operations that reverse each other, because another thread may find the modified value in-between. That's true even for relaxed memory access, which ref counts are not. > [Sidenote: There's a reason the C++-standard disallows reference counting > for its string class.] There is, but this isn't it. The concern is the unexpected memory allocation when calling a non-const function. The standard banned reference counting by requiring a few of those functions to have constant time (O(1)) operation, which can't be implemented if you need to allocate memory and memcpy. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Roll our own qUtf8Printable()?
On domingo, 25 de fevereiro de 2018 15:00:38 PST Lubomir I. Ivanov wrote: > <bstoe...@mail.tuwien.ac.at> wrote: > > Dear all, > > > > In many places, QStrings are converted to C-style strings with an > > expression of the kind > > > > s.toUf8().data() > > > > I have a patch replacing all of them with > > > > qUtf8Printable(s) > > > > The idea is that - according to the documentation - this is equivalent to > > > > s.toUtf8().constData() > > > > The latter should produce less machine code, because it doesn't have to > > check whether the data of the temporary QByteArray is shared. Owing to > > the many indirections in Qt's code, the compiler is not smart enough to > > understand that in this case data() = constData(). It couldn't and shouldn't. toUtf8() returns a non-const QByteArray, so .data() calls the non-const version which will in turn try to detach. However, the data isn't shared, which means this is just a useless branch-and-compare. The performance impact should be negligible, except in tight loops, and most definitely dwarfed by the memory allocation that involved creating that UTF-8 string in the first place. I've got some code that will try to gift the memory from the QString to the QByteArray, but it can't be done in Qt 5 without breaking binary compatibility. > > Much to my surprise, qUtf8Printable() produced larger code. The reason is > > that it is defined as a macro in : > > > > #ifndef qUtf8Printable > > # define qUtf8Printable(string) QString(string).toUtf8().constData() > > #endif > > > > It generates a temporary copy of the string! This looks like a defect to > > me. Not really, but we may be able to improve it. It's done that way because you want this to work: qUtf8Printable(someString + ":" + otherString) When the fast operator+ is active, the expression in the parentheses isn't a QString, but a QStringBuilder<QStringBuilder<QString, char[2]>, QString>, which does a single memory allocation with no temporaries, instead of the expected two allocations. So we need to get it to convert to QString first before we can call .toUtf8() on it. This also works if the macro parameter is anything else that can be implicitly converted to QString, like QLatin1String. So if you wrote: qUtf8Printable(QLatin1String("\xe9")) You'd get the expected "\xc3\xa9" output. But, like I said, there may be a way to improve that. It's not what you suggested here: > > So what do you think about rolling our own helper function: > > > > inline const char *qstring2c(const QString ) > > { > > > > return s.toUtf8().constData(); > > > > } The above is just wrong. The pointer that is returned is dangling, because the above code actually does: QByteArray temp1 = s.toUtf8(); const char *temp2 = temp1.constData(); temp1.~QByteArray(); return temp2; Since the temporary QByteArray owns the pointer, it will free the pointer before the function returns. Any and all use of that pointer is strictly UB. That's also why both qPrintable and qUtf8Printable are macros, instead of inline functions. Many a novice contributor to Qt has made such a proposal to convert macros to inline functions and stumbled upon this mistake, myself included (though over 10 years ago). > hi, Thiago. > > if you have a moment, what do you think about the size differences > between qUtf8Printable() and the proposed home brew qstring2c() > replacement. > Berhold is saying that qUtf8Printable() always creates a copy of the > string, does that seem right? No, it doesn't. But there's another option, which is to avoid a copy of the QString if the input is already a QString. Let me try a few variations of possible solutions and compile Qt to see what happens. I'll BRB. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Compiling Subsurface against Qt in debug/developer mode
On terça-feira, 26 de dezembro de 2017 08:15:06 -02 Jan Mulder wrote: > Currently, I'm (test) compiling Subsurface against the relatively new Qt > 5.10, which I compiled myself in developer mode. As the Qt source > contains numerous asserts that are only active in developer mode, I > (obviously) trip some of them while using our Subsurface (see for > example, PR #977). > > So, my question is now: what to do with this knowledge? When there is an > obvious fix (like in 977), there seems no reason not to fix this in > Subsurface. But now, I am stuck on a very deep down assert triggered by > the new filter code. This code seems to work just fine in production > code, and a fix on our side seems not straightforward. It might even be > a bogus assert in Qt, or a bug in Qt. > > So, another question: what do the Qt specialists here think of the > "quality of the asserts in Qt source?". Are they of any use to non-Qt > developers? Obviously, our main objective here is to improve Subsurface > and not trying to debug Qt. That said, we might improve out code by > assuming the Qt asserts are valid and correct, and improve our code not > to trip those. Assertions inside Qt code, like all warnings printed by Qt, are meant to indicate errors in the application's usage of the Qt API. So please investigate whether we have a mistake in Subsurface. If you find out that it's a valid condition but the assertion or warning was incorrectly printed, file a bug report with an explanation of how you reached it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface as a Snap?
On quinta-feira, 21 de dezembro de 2017 13:15:53 -02 Dirk Hohndel wrote: > Snap is a Canonical effort and as such is receiving at best "lip-service" > level support from the other distros. FlatPak was very much developed by > Red Hat as a response to Snap and as a direct competitor. As a result > (isn't it lovely), neither of them has good support on the other one's > platform. Even though both of course claim that they do. Red Hat is contributing new features to Qt in order to support FlatPak, like supporting the FlatPak D-Bus portal service to show file dialogs and allow selecting of files outside of the sandbox. I have not seen any patch for Canonical for Snap. For that matter, neither for AppImage. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Switching to Qt 5.10
On sexta-feira, 8 de dezembro de 2017 05:49:34 PST Dirk Hohndel wrote: > > On Dec 8, 2017, at 7:46 AM, Thiago Macieira <thi...@macieira.org> wrote: > > > > On Friday, 8 December 2017 03:21:04 PST Dirk Hohndel wrote: > >> Actually, I just wanted to switch to Qt 5.10 and start testing with that. > > > > Please note that 5.10.0 has problems renaming files on Android, due to an > > unexpected SELinux rule. I advise to wait for 5.10.1. > > Thank you for that warning! > > I started looking at 5.10.0 for iOS, haven't even looked at Android, yet. > I will hold off. Is there an ETA for 5.10.1 (since that's a pretty > catastrophic bug)? I don't know if Subsurface uses Qt for renaming files. It doesn't affect QTemporaryFile, QSaveFile and QSettings, though. 5.10.1 should be out just after new years. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Switching to Qt 5.10
On Friday, 8 December 2017 03:21:04 PST Dirk Hohndel wrote: > Actually, I just wanted to switch to Qt 5.10 and start testing with that. Please note that 5.10.0 has problems renaming files on Android, due to an unexpected SELinux rule. I advise to wait for 5.10.1. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ReleaseNotes.txt and merge conflicts
On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov wrote: > > Isn’t this what we are looking for: > > > > http://krlmlr.github.io/using-gitattributes-to-avoid-merge-conflicts/ > > i think, yes. that's exactly what we are looking for. > i wonder if it would work with the current ReleaseNotes.txt layout > where lines are inserted at the bottom of a new release and on top of > old ones. i guess i can test it. Since we're using GitHub itself to do the merges, can you confirm that it does respect this .gitattributes attribute? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ReleaseNotes.txt and merge conflicts
On Monday, 27 November 2017 14:19:50 PST Lubomir I. Ivanov wrote: > maybe we can think of a mechanic to avoid the release note conflicts, > as these are more common now that everyone edits the file next to a > pull request. The way we do in Qt is to add it to the commit message. Later, in the release process, we run a script that collects all entries and produces the file. If we want to use the Qt script, the format is: [ChangeLog][Area1][Area2] Text text. The Area2 is optional. Each entry is a separate Git commit message paragraph, so it can be wrapped around multiple lines and needs to be separated from other text (including other entries) by a blank line. See as an example: http://code.qt.io/cgit/qt/qtbase.git/commit/? id=92ca09147fc239762927595165f71a0d1ecff98f -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: bool different in C and C++?
On sábado, 18 de novembro de 2017 08:19:41 PST Berthold Stoeger wrote: > in core/pref.h we find the comment > /* can't use 'bool' for the boolean values - different size in C and C++ */ The comment is wrong. It's been wrong for 18 years, since C99 introduced stdbool.h. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: no luck with Qt 5.9.2
On Tuesday, 24 October 2017 10:32:10 PDT Jan Mulder wrote: > > I can help poke people, though. Can you report the current findings so > > I'll > > poke people? > > created QTBUG-64017 Thanks Jan Let's see what the maintainers say. Did I mention I find the disk cache a hacky feature? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: no luck with Qt 5.9.2
On Tuesday, 24 October 2017 08:30:14 PDT Tomaz Canabrava wrote: > > I found one commit that is in Qt 5.9.2 (and not in 5.9.1) called "Fix qml > > cache invalidation when changing dependent C++ registered QML singletons" > > (commit 98358715930739ca8de172d88c5ce6941c275ff3 in qtdeclarative). > > Related > > to QTBUG-62243. > > > > The rationale of that commit is fully sane to me, but ... I reverted this > > one, and my problem of unable to start Subsurface-mobile build with 5.9.2 > > (on desktop, for now) due to a silent failure of engine.load("main.qml") > > is > > gone, and the mobile-on-desktop app runs correctly as before. > > > > So, now the big question is ... how to proceed? I still cannot rule out > > that > > the whole issue is a result of some (still unknown) bug in Subsurface > > itself, or Kirigami or ... But, building a tiny bug demonstrator for Qt > > might be over my skill set :-) > > > > For anyone that might wonder how I found this suspicious commit ... I > > found > > earlier that the Kirigami file Units.qml was involved, and that is a > > singleton type object. That made me search for singleton related code > > changes in Qt. > > This is something that we can poke thiago, and thiago can poke more people. > And it's a serious issue as this can break a lot of usecases of qt. And he did. The first thing we should do is file a bug with the findings so far and the symptoms, even if we can't provide a reduced testcase. Further from that, I can't directly help, since I have no idea about the QML internals. I do know that the QML caching feature is something I have problems with, but that's usually because I build from sources and not from releases. Intermediary builds can leave corrupt caches. I can help poke people, though. Can you report the current findings so I'll poke people? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
On Friday, 25 August 2017 12:50:01 PDT Lubomir I. Ivanov wrote: > do you happen to have qtlocation5-private-dev in the package manager? I asked the packagers. They said they don't want to create the -private-dev packages if they can avoid it, since it is too tempting for other packagers to use them. Since Qt does not offer API/ABI stability in the private headers, anything that depends on -private-dev must be rebuilt whenever Qt changes anything. They're too few people to keep track of this and it takes too much resource (one week to rebuild everything -- remember that Debian supports some platforms for which there's no fast hardware). But he did confirm that they do not patch them, so they should match the tag from the Qt repositories. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
On Friday, 25 August 2017 12:43:28 PDT Lubomir I. Ivanov wrote: > about the private headers not being available - i just read in a > github project that some distros simply do not include them, so one > has to download the offline Linux installer of Qt from here - > https://www.qt.io/download-open-source/#section-2. Most distros do include them. Fedora has them in the regular package: https://koji.fedoraproject.org/koji/rpminfo?rpmID=10536754 OpenSUSE has in separate "private-headers-devel" packages: https://build.opensuse.org/package/binaries/openSUSE:Leap:42.3/libqt5-qtbase? repository=standard -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Sunday, 6 August 2017 00:07:30 PDT Dirk Hohndel wrote: > While I don't even pretend to be a security expert, this is a topic that I > have quite some familiarity with. Yes, right now OpenSSL 1.0.2 (latest) is > still considered "as secure" as 1.1.0 latest. I can understand the Qt team > delaying this migration for 5.10 as it is quite painful. There's also a licensing component here. One cannot distribute GPLv2-only software linking to OpenSSL 1.1. Subsurface is GPLv2-only, isn't it? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Sunday, 6 August 2017 18:42:24 PDT Linus Torvalds wrote: > On Sat, Aug 5, 2017 at 9:16 PM, Thiago Macieira <thi...@macieira.org> wrote: > > Patch and diff links in > > http://code.qt.io/cgit/qt/qtbase.git/commit/? > > id=cfbe03a6e035ab3cce5f04962cddd06bd414dcea > > It doesn't really apply cleanly, but it's fixable, so I have 5.9 on F26 > working. dbb2374d20959472ca379a38c37774518eef5bfe, dc8bfab82eb051a516a4138e50f2d8de5095319e and f78a189da5d9e13a96a52b9d17cdc80df06ed8c8 also touch those same files and they appear between current 5.9 branch tip and the OpenSSL 1.1 commit above. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Saturday, 5 August 2017 17:07:50 PDT Linus Torvalds wrote: > You don't use old versions of security software. It's that easy. Not done, > not acceptable, not a solution. To be clear: OpenSSL 1.0.2l was released on the very same day as 1.1.0f. Both branches are currently maintained. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Saturday, 5 August 2017 20:54:59 PDT Linus Torvalds wrote: > On Aug 5, 2017 20:48, "Thiago Macieira" <thi...@macieira.org> wrote: > > From the Qt Project's point of view, it's a new feature, so it was added to > the devleopment branch. But it seems the patch is clean enough to be > backported if a Linux distribution wants it for its purposes. > > Christ, you people have some odd ideas about "new features". Like that > while "it compiles" thing. Small new feature, that. I agree on the "it compiles", but those at fault are the OpenSSL developers for suddenly breaking source compatibility with no grace period. See https://www.mail-archive.com/tech@openbsd.org/msg36437.html for someone else complaining about the same issue (no, not Theo). From Qt's point of view, it's a large refactoring of a central piece of technology. We couldn't add it to the stable release without further testing. Timing also didn't help: Qt 5.9 had already been feature frozen for almost two months when the patch was first uploaded (no idea when the author first began working on it). > Can you point me to the actual patch that is clean enough to backport? Lubomir sent the link, which includes all 63 iterations of the patch: https://codereview.qt-project.org/189399 Patch and diff links in http://code.qt.io/cgit/qt/qtbase.git/commit/? id=cfbe03a6e035ab3cce5f04962cddd06bd414dcea -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Saturday, 5 August 2017 17:07:50 PDT Linus Torvalds wrote: > I did see some patches, and another big report that was allegedly closed > because of those patches, but they don't actually seem to be merged > although the bug report said they were upstream. I suspect that there is > some branch that worked at some point. They are, but in Qt 5.10. You're building 5.9.1. From the Qt Project's point of view, it's a new feature, so it was added to the devleopment branch. But it seems the patch is clean enough to be backported if a Linux distribution wants it for its purposes. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt 5.9 openssl problems on F26
On Saturday, 5 August 2017 15:40:01 PDT Linus Torvalds wrote: > Ok, I've worked around this by just using my old build, but it means > that ssl doesn't work, which in turn means that I can't actually do > the cloud access etc on my F26 desktop. > > So I'm tried of my old broken At-5.9 build, and would like to know how > to make a proper build against openssl-1.1.0, which is what F26 has. OpenSSL 1.1 is work in progress for Qt. You have to use 1.0. OpenSSL developers decided to break source compatibility and we haven't had time to adapt. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: latest Windows binary crashes
On segunda-feira, 3 de julho de 2017 14:32:35 PDT Dirk Hohndel wrote: > Grumble. > > I was told on the Qt list that there is a MUCH newer branch that I should > try - they have updated to a current WebKit. The thing that's odd... between > 5.7.1 (which the Windows binaries used to be based on) and 5.9 there > shouldn't really have been any WebKit changes... so why does it crash now. There are a number of minor changes submitted to the 5.8 and 5.9 branches by people like Konstantin, Allan and me. Mine were mostly just to make it, but looking at the diff there appear to be a couple of backports from upstream. > > i mean i can possibly find the offending line of code, but i won't > > really have a good fix for it. after seeing that unpredictable Marble > > multi-threading crash on Windows, i think we are entering the > > territory of big, complicated but unmaintained libraries that simply > > may not run with the latest Qt version. Qt 6.0 is coming too... > > I think they are working on 5.10 ... Qt 6.0 will be discussed at the Contributor Summit this year in Berlin. The current idea is that 5.12 will be LTS and then 6.0. That would put 6.0 about two years away from now. > > so we need to: > > 1) move away from these unmaintained libraries > > WebKit - currently we are stuck with WebKit on Windows > > Grantlee - we are stuck with Grantlee due to the template syntax which > > the users are already using > > Marble - we probably should start using a 2D map of sorts > > WebKit - I think we are stuck with that for a while > Marble - Tomaz has this working with the latest, maintained Marble > Grantee - I have this working on Mac What happened to the idea of using QtLocation for maps? > > BTW you can try building this QtWebKit port as it's actively updated: > > https://github.com/annulen/webkit/releases > > Yes, and that appears to be in the 5.212 branch of Qt that I need to > find the time to investigate... 5.212 builds with CMake, not qmake anymore. My recommendation is that you build it after all the rest of Qt. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Dive download crash - Qt model issues
On sábado, 24 de junho de 2017 11:05:25 PDT you wrote: > The solution to that problem is "--developer-build". That actually > does exactly the right thing from a "build one single app against the > special Qt tree that has a couple of experimental patches" > perspective. You can just do -prefix $PWD/qtbase if you're building from the top-level qt5.git. You can also build only qtconnectivity on top of your existing libs and not install it. With LD_LIBRARY_PATH and QT_PLUGIN_PATH environment variables set, you should be able to run without installing too. > Honestly, I'd probably prefer a non-debug developer mode, but the > extra debug printouts it also seems to cause were actually super > helpful for getting BLE going. That should not have affected the debugging output... It seems to be a Fedora patch: https://src.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtlogging.ini You can override it by setting QT_LOGGING_RULES=*.debug=true -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Dive download crash - Qt model issues
On sábado, 24 de junho de 2017 10:16:06 PDT Linus Torvalds wrote: > Now, it may be that (once more) this is because I run my self-compiled > Qt, and apparently it ends up adding more sanity checks and asserts > when built in developer mode. Going off on a tangent here, but... Qt has release mode, debug mode and the "-developer-mode" switch. Be careful not to confuse the latter two: developer mode is debug mode but enables a few extra things so Qt's own unit tests can run, like exporting some functions so they can be called from the tests. Another consequence is that it compiles with -Werror and compiles each header individually, so the build time increases and you're more likely to get build failures. Unless you're developing Qt itself like me, you don't want that option. Debug mode is fine for debugging into Qt itself and enables Q_ASSERT. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: QtWebEngine and Mingw
On sábado, 24 de junho de 2017 08:40:49 PDT Lubomir I. Ivanov wrote: > to summarize: > this leaves in a bit of a stalemate and unless Thiago has some sort of > an idea, Sorry, I don't have an idea. > we should just stick with WebKit for as long as possible, or > until: > 1) clang WebEngine binaries can be used from mingw binaries I don't think they can. The one being discussed here is the target "x86_64- windows" which is compatible with MSVC (a.k.a clang-cl), not "x86_64-mingw" which is compatible with MinGW. > 2) if we can build the whole Subsurface project using clang for > Windows and WebEngine is also built using clang Which is the same as switching to MSVC and build on Windows. My experience with clang-cl isn't very good, but at least you an mix it with MSVC and use 2015 or 2017 where Clang-cl is still lacking. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: MacBook Pro El Cap vers 10.11.6 (15G1510) Subsurface ver Subsurface v4.6.4
On Thursday, 15 June 2017 16:42:43 PDT Lubomir I. Ivanov wrote: > On 16 June 2017 at 00:38, Dirk Hohndel <d...@hohndel.org> wrote: > > On Thu, Jun 15, 2017 at 03:07:43PM +, Tomaz Canabrava wrote: > >> We really need to update marble on subsurface, I'll try to do that. > > > > The problem is that we have quite a few significant changes in our branch > > that remove features and fix issues we ran into. And keeping up with > > upstream was a major pain. I thought we talked about using the Qt map > > thingy instead of Marble - I'd much prefer that than spending more time on > > Marble. > > why not try to use the google maps API directly inside a html page in > a Qt web-engine, with a no-restrictions google maps API key. > (i suggested similar before we started using marble) Please note that deploying a web engine is not permitted on iOS. So you need both a solution using qtwebengine (for desktops) and qtwebview (for mobile phones). I'd investigate qtlocation first, just to see if it solves the problem. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: MacBook Pro El Cap vers 10.11.6 (15G1510) Subsurface ver Subsurface v4.6.4
On Thursday, 15 June 2017 14:38:23 PDT Dirk Hohndel wrote: > The problem is that we have quite a few significant changes in our branch > that remove features and fix issues we ran into. And keeping up with > upstream was a major pain. I thought we talked about using the Qt map > thingy instead of Marble - I'd much prefer that than spending more time on > Marble. Qt Location? The newer versions have nice support by MapBox, maintained in upstream by MapBox people. But it's a map, not a globe. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault when trying to edit cylinder information
On terça-feira, 13 de junho de 2017 13:16:21 PDT Lubomir I. Ivanov wrote: > i cannot reproduce the problem, but also the above should not happen > as we allocate the cylinder "type" (tank_info_t->name) on the heap and > it's address cannot be so low (0x1770). It comes from: struct tank_info_t *info = _info[index.row()]; which is a global variable in core/equipment.c: struct tank_info_t tank_info[100] = { ... }; and has been so since 2013. I don't see how a) tank_info could be wrong (unless it's a major compilation problem) and b) how index.row() could have been so exactly wrong to produce a pointer in the second memory page (it's too much of a coincidence) Not to mention that index was created by QComboBox, as a result of resize operation, so even if there's another QModelIndex in the stack, it shouldn't have had an effect -- not to mention that those were also generated by Qt. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74
On terça-feira, 13 de junho de 2017 03:09:51 PDT Linus Torvalds wrote: > I seem to be the only one getting this, and I don't get it reliably > either. It seems to be timing-related somehow, because it never > happens under gdb, but I *can* catch it with a core-dump and then get > gdb to show me where it is. Backtrace appended in case it makes > anybody go "yeah". > > This may be because I'm doing something wrong when I had to build my > own Qt-5.9 (for doing BT). It seems to be some interaction with > Marble. The reason you may be getting this and no one else is that you did build your Qt so it's got assertions enabled. For everyone else, with them disabled, the code is just faulty but silent. > (gdb) p bytes > $1 = 115 > (gdb) p bufferSize > $2 = 0 Any other threads running at this time? This smells like a race condition and caused by the Marble's "don't print debug" debugging functionality. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Initial crash in MacOS Sierra
On sexta-feira, 26 de maio de 2017 12:53:54 PDT Thiago Macieira wrote: > On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote: > > Thiago, > > > > could you please have a look at this: > > https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-3 > > 0 > > 1407498 > > > > User reports Subsurface crashing on start up and it seems it is in the > > intial network operation where it determines if it is the latest version. > > Somehow it seems Qt-networking is calling into CoreFoundations with an > > illegal nil argument. > > > > Needless to say, I cannot reproduce this problem here. > > Hi Robert > > I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet. > I'm trying to fight CMake so that it will find OpenSSL properly: my Mac is > a little unusual in that I didn't install the Xcode Command Line tools, but > instead I added > > /Applications/Xcode.app/Contents/Developer/Toolchains/ > XcodeDefault.xctoolchain/usr/bin > > to $PATH instead. So I keep getting now: > > ld: library not found for -lssl > > The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the > newest Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib. That was easy to fix: just drop -lssl -lcrypto from the command-line. Then it links without errors. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Initial crash in MacOS Sierra
On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote: > Thiago, > > could you please have a look at this: > https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-30 > 1407498 > > User reports Subsurface crashing on start up and it seems it is in the > intial network operation where it determines if it is the latest version. > Somehow it seems Qt-networking is calling into CoreFoundations with an > illegal nil argument. > > Needless to say, I cannot reproduce this problem here. Hi Robert I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet. I'm trying to fight CMake so that it will find OpenSSL properly: my Mac is a little unusual in that I didn't install the Xcode Command Line tools, but instead I added /Applications/Xcode.app/Contents/Developer/Toolchains/ XcodeDefault.xctoolchain/usr/bin to $PATH instead. So I keep getting now: ld: library not found for -lssl The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the newest Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 1/1] Don't use the deprecated CMake variable
The *_VERSION_STRING variable has been deprecated in Qt since 5.1.0. Use the non-deprecated variable instead (which is not a string). Qt 5.9.0 has a bug in the deprecated variable. Since it's deprecated, it's probably not going to be fixed until 5.9.1. See https://bugreports.qt.io/browse/QTBUG-60936 Signed-off-by: Thiago Macieira <thi...@macieira.org> --- CMakeLists.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index cca2c0a3..bcdf6cd5 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -218,9 +218,9 @@ set(QT_LIBRARIES Qt5::Core Qt5::Concurrent Qt5::Widgets Qt5::Network Qt5::Svg Q set(QT_TEST_LIBRARIES ${QT_LIBRARIES} Qt5::Test) #disable bluetooth if Qt version is ancient. -if (BTSUPPORT AND "${Qt5Core_VERSION_STRING}" STRLESS "5.4.0") +if (BTSUPPORT AND "${Qt5Core_VERSION}" VERSION_LESS 5.4.0) set(BTSUPPORT OFF) - message(STATUS "Turning off Bluetooth support as Qt version ${Qt5Core_VERSION_STRING} is insufficient for that") + message(STATUS "Turning off Bluetooth support as Qt version ${Qt5Core_VERSION} is insufficient for that") list(REMOVE_ITEM QT_LIBRARIES Qt5::Bluetooth) endif() -- 2.12.2 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH 1/1] Adapt build.sh if qmake is already in PATH on a Mac
Some people (like me) have Qt elsewhere. So long as qmake is in PATH, we should be able to support it. Signed-off-by: Thiago Macieira <thi...@macieira.org> --- scripts/build.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/build.sh b/scripts/build.sh index 1e64b515..88437c76 100755 --- a/scripts/build.sh +++ b/scripts/build.sh @@ -174,7 +174,11 @@ if [ $BUILDMARBLE = 1 ]; then mkdir -p build cd build if [ $PLATFORM = Darwin ] ; then - if [ -d "$HOME/Qt/5.8" ] ; then + # qmake in PATH? + libdir=`qmake -query QT_INSTALL_LIBS` + if [ $? -eq 0 ]; then + export CMAKE_PREFIX_PATH=$libdir/cmake + elif [ -d "$HOME/Qt/5.8" ] ; then export CMAKE_PREFIX_PATH=~/Qt/5.8/clang_64/lib/cmake elif [ -d "$HOME/Qt/5.7" ] ; then export CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64/lib/cmake -- 2.12.2 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Initial crash in MacOS Sierra
On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote: > Thiago, > > could you please have a look at this: > https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-30 > 1407498 > <https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-3 > 01407498> > > User reports Subsurface crashing on start up and it seems it is in the > intial network operation where it determines if it is the latest version. > Somehow it seems Qt-networking is calling into CoreFoundations with an > illegal nil argument. > > Needless to say, I cannot reproduce this problem here. Story of our lives :-) I'll take a look later this week. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: sudo 4.6.4 Aborted
On segunda-feira, 15 de maio de 2017 08:40:38 PDT Dirk Hohndel wrote: > > On May 15, 2017, at 8:32 AM, Thiago Macieira <thi...@macieira.org> wrote: > > > > On segunda-feira, 15 de maio de 2017 06:38:51 PDT Dirk Hohndel wrote: > >> I understand that. For us as a user of the library, though, having the > >> app > >> crash on something as trivial as not being able to connect to the > >> display, > >> that does seem a bit crude. > > > > I know. It's a side-effect of not using exceptions: we have no way of > > reporting that the connection failed, aside from aborting the application. > > > > Would a change to _exit help? > > The app reporting an error and calling _exit() (which means no "crash" > message to the user) would be preferable in my view. I think I can justify that change. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: sudo 4.6.4 Aborted
On segunda-feira, 15 de maio de 2017 06:38:51 PDT Dirk Hohndel wrote: > I understand that. For us as a user of the library, though, having the app > crash on something as trivial as not being able to connect to the display, > that does seem a bit crude. I know. It's a side-effect of not using exceptions: we have no way of reporting that the connection failed, aside from aborting the application. Would a change to _exit help? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: sudo 4.6.4 Aborted
On domingo, 14 de maio de 2017 23:22:55 PDT Martin Měřinský wrote: > > we should fix the reason you run as root in the first place. > > > > > Because importing dives from DC doesn't work for me as a user. So > > > for > > > the short moment I run Subsurface as a root. > > > > > > I tried, what manual says, but it didn't work. > > > > > > sudo usermod -a -G dialout mermar > > > sudo usermod -a -G uucp mermar > > > > > > subsurface divelog.2017-04-10.xml > > > Insufficient privileges to open the device /dev/ttyUSB0 Suunto > > > (HelO2) > > > > Can you send us the output of > > > > ls -l /dev/ttyUSB0 > > crw-rw 1 root dialout 188, 0 kvě 15 08:21 /dev/ttyUSB0 And did you log out and then back in after running the usermod command? Check that the "id" command shows dialout. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: sudo 4.6.4 Aborted
On domingo, 14 de maio de 2017 21:52:56 PDT Dirk Hohndel wrote: > Ah, apparently this is a Qt bug that was declared not a bug at some point > (you can find quite a few threads about this), and the way to work around > it is to implement your own Logger class and exit() instead of abort() > when you get a "Could not connect to display error". > > Not one of the more useful aspects of Qt, I'd like to add... Unfortunately, exit() is often harmful in C++ programs, since the global & atexit destructors are run, but the stack hasn't been unwound so objects in the main() function continue to exist. This breaks a number of assumptions about the order in which things are destroyed (namely, that it is the opposite in which they were constructed). Using _exit() might help, but it may bring its own set of problems. At least it's closer to the qFatal call that is there now. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: sudo 4.6.4 Aborted
On domingo, 14 de maio de 2017 21:20:01 PDT Martin Měřinský wrote: > sudo subsurface divelog.xml > [sudo] password for mermar: > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime- > root' > No protocol specified > QXcbConnection: Could not connect to display :0 > Aborted (core dumped) Your X server refused the connection. Best solution: don't use sudo. In fact, don't run Subsurface as root. Why were you trying this? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
On quarta-feira, 19 de abril de 2017 03:45:46 PDT Lubomir I. Ivanov wrote: > void MarbleDebug::setEnabled(bool enabled) > { > QLoggingCategory::setFilterRules(QString("marble.debug=%1").arg(enabled > ? "true", "false")); > } > > and likely remove isEnabled() as it's not needed? Sounds good, but do we need this setEnabled() in the first place? Is it used anywhere? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
Em terça-feira, 18 de abril de 2017 00:08:57 PDT você escreveu: > I will try it this morning. > Two remaining questions: > - What is the default state now if we don't set it explicitly? Enabled true > or false? Depends on the argument passed in the macro. With QtDebugMsg, it defaults to enabled; with QtWarningMsg, it defaults to disabled. > - Where would be the right place in Subsurface code to put the > MarbleDebug::setEnabled(false) ? If we want it disabled by default, just change the macro. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
Em terça-feira, 18 de abril de 2017, às 09:23:12 PDT, Stefan Fuchs escreveu: > /home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/MarbleDebug > .cpp:27:53: error: passing 'const QLoggingCategory' as 'this' argument of > 'void QLoggingCategory::setEnabled(QtMsgType, bool)' discards qualifiers > [-fpermissive] loggingCategory().setEnabled(QtDebugMsg, enabled); Hold on. This one is weird, because how can you call that non-const method if everything is const? Kai, how is one supposed to call QLoggingCategory::setEnabled()? Or are we not supposed to? Or should we skip the Q_LOGGING_CATEGORY macro and deploy our own code? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
On segunda-feira, 17 de abril de 2017 14:53:12 PDT Lubomir I. Ivanov wrote: > Stefan, could you please try building and running the attached patch? > you can toggle the debugging with MarbleDebug::setEnabled(true/false) > e.g. from the Subsurface source code. Or by setting in your environment: QT_LOGGING_RULES=marble.debug=true -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
On segunda-feira, 17 de abril de 2017 14:41:13 PDT Lubomir I. Ivanov wrote: > On 18 April 2017 at 00:18, Thiago Macieira <thi...@macieira.org> wrote: > > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote: > >> i guess we could just do a: > >> void MarbleDebug::setEnabled(bool enabled) > >> { > >> > >> Marble::loggingCategory.setEnabled(enabled); > >> MarbleDebug::m_enabled = enabled; > >> > >> } > > > > I'd go a little further and drop the m_enabled variable completely. You > > don't need it, let the bit in the QLoggingCategory variable keep the > > state. > > > > You'd have: > > > > namespace MarbleDebug { > > Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg) > > > > void setEnabled(bool enabled) > > { > > > > category.setEnabled(QtDebugMsg, enabled); > > > > } > > > > bool isEnabled()// do you even need this function? > > { > > > > return category.isDebugEnabled(); > > > > } > > } //namespace MarbleDebug > > > > This changes to the MarbleDebug namespace too. > > thanks, i think i understand. > > here are the updated Marble files and a patch diff for review. > i can't build Marble to test these changes ATM though. Looks good, so long as "Marble::category" isn't too generic a name. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote: > i guess we could just do a: > void MarbleDebug::setEnabled(bool enabled) > { > Marble::loggingCategory.setEnabled(enabled); > MarbleDebug::m_enabled = enabled; > } I'd go a little further and drop the m_enabled variable completely. You don't need it, let the bit in the QLoggingCategory variable keep the state. You'd have: namespace MarbleDebug { Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg) void setEnabled(bool enabled) { category.setEnabled(QtDebugMsg, enabled); } bool isEnabled()// do you even need this function? { return category.isDebugEnabled(); } } //namespace MarbleDebug This changes to the MarbleDebug namespace too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device
On segunda-feira, 17 de abril de 2017 13:24:26 PDT Lubomir I. Ivanov wrote: > On 17 April 2017 at 22:29, Thiago Macieira <thi...@macieira.org> wrote: > > On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov wrote: > >> QDebug mDebug() > >> > >> { > >> > >> return QDebug( QtDebugMsg ); // or "return qDebug();" > >> > >> } > >> > >> which will essentially enable debug output for everything in Marble, > >> until we write a dummy Class with an overloaded << operator to void > >> all the incoming debug calls. > > > > It would be better to use a category and then simply turn the category > > off. It can be enabled manually by users with QT_LOGGING_RULES > > environment variable. > > > > See http://doc.qt.io/qt-5/qloggingcategory.html. > > thanks, for the suggestion, Thiago. > > Stefan, could you please test the attached patch and if it works, > submit it to Github for approval. This disables the debug output for the default category, that is, every user of qDebug(). I was suggesting turning mDebug() into qCDebug(...). // in a header namespace Marble { Q_DECLARE_LOGGING_CATEGORY(loggingCategory) } #define mDebug qCDebug(Marble::loggingCategory) // in one source file namespace Marble { Q_LOGGING_CATEGORY(loggingCategory, "marble", QtWarningMsg) } -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Haunting a Windows "Subsurface not start but becoming zombie" bug
Em domingo, 9 de abril de 2017, às 16:47:25 PDT, Lubomir I. Ivanov escreveu: > g++ test.cpp -Wall -std=c++11 -O1 -S -o test-meyer.S > > so, it's guarded with ___cxa_guard_acquire() and it appears that the > c++11 flag doesn't matter much. That's because GCC has used thread-safe initialisation of function statics for a long time. I know it was specified in the IA-64 C++ ABI, dating from 1999, but it's possible GCC supported it for longer (3.3 or earlier). But it wasn't part of the C++ language specification. It only said that "if the initialisation is reentered, behaviour is undefined". So other compilers did not need to implement it. C++11 did add a requirement that such initialisation must not deadlock. This is known to trip several implementations. Apple operating systems are known to fail that second bit too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Detect location of `ldconfig' before use
On domingo, 5 de fevereiro de 2017 12:53:38 PST Cristian Ionescu-Idbohrn wrote: > + _ldconfig=$(PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH command -v > ldconfig) || { + echo "can't find ldconfig" >&2 > + exit 1 > + } > + LIBGIT=$($_ldconfig -p | grep libgit2\\.so\\. | awk -F. '{ print $NF > }') Instead of trying to find it, I'd just do: ldconfig 2>/dev/null || true -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Qt and subsurface for Android
On segunda-feira, 9 de janeiro de 2017 21:59:40 PST Anton Lundin wrote: > > I'm having this same problem. I thought it was my version of cmake, and > > ended up updating my dist from wily to xenial (LTS) and then yakkety. > > Still > > no luck. I may try the above hack later... but is that the correct fix? > > https://bugreports.qt.io/browse/QTBUG-54666 > > Sounds like cmake 3.7(!) might be the "fix". > > > I currently just cmake || true so bash don't aborts on the return code, > and it builds just fine. See also the discussion in https://bugreports.qt.io/browse/QTBUG-57886. This is a CMake bug in that it fails to recognise the Clang for Android being a useful compiler. The bug report has a workaround, something about setting CMP0025. I have no idea what that means or how to do it. Someone who understands CMake should read the bug report and apply the fix. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: since we are testing things on Mac...
On domingo, 1 de janeiro de 2017 18:33:02 BRST Dirk Hohndel wrote: > For kicks and giggles I dug out an almost ten year old Mac running 10.6. > That one will happen. Qt is limited to 5.3 on that for example. And we > don't have a C++11 compiler... That's ok, Qt 5.3 didn't require it (Qt 5.6 doesn't either). The problem is the compiler itself, though. Apple's GCC 4.2 was stuck in time for a long time, with known miscompilation bugs. If you can get Clang to work, it would be the best result. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: anyone with a Mac running 10.7 or 10.8?
Em domingo, 1 de janeiro de 2017, às 09:48:01 BRST, Dirk Hohndel escreveu: > > On Jan 1, 2017, at 6:58 AM, Thiago Macieira <thi...@macieira.org> wrote: > > > > It is the old AVX bug. VXORPS is an AVX instruction (that V is the tell) > > And this library comes from OpenSSL which we get from HomeBrew. I can > already see that I will hate where all this will take me, but I appreciate > that thanks to Robert's access (if somewhat limited) to such an old machine > we got reminded of the issue... > > Doing some more research, it seems that not a lot of Macs should fall into > the narrow overlap of "able to run 10.7 and don't have AVX". But I'll see > what I can do. I think HomeBrew by default builds targetting the local machine (- march=native), which makes the binaries unsuitable for distribution. There's a switch somewhere to make it build generic binaries. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: anyone with a Mac running 10.7 or 10.8?
It is the old AVX bug. VXORPS is an AVX instruction (that V is the tell)Sent from my BlackBerry — the most secure mobile deviceFrom: hell...@atdotde.deSent: 1 January 2017 12:54 p.m.To: thi...@macieira.orgCc: subsurface@subsurface-divelog.orgSubject: Re: anyone with a Mac running 10.7 or 10.8? On 01 Jan 2017, at 14:07, Robert Hellingwrote:that was quick: Xcode requires at least 10.11.5 … luckily, knowing the URL one can download old developer disks. So, here we go:* thread #1: tid = 0x1f03, 0x0001043eb574 libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) frame #0: 0x0001043eb574 libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12:-> 0x1043eb574: vxorps %xmm0, %xmm0, %xmm0 0x1043eb578: vmovaps%xmm0, -48(%rbp) 0x1043eb57d: movq %rsi, -32(%rbp) 0x1043eb581: movl %edx, -24(%rbp)As I don’t speak i386 assembly, I have no idea what that means.BestRobert___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: anyone with a Mac running 10.7 or 10.8?
Apologies about top-postingDoesn't OSX generate a crash report? It should be possible to debug on your regular Mac. If not, we can probably guess what instruction it was: do you know what processor this old mini of your has? Sent from my BlackBerry — the most secure mobile deviceFrom: hell...@atdotde.deSent: 1 January 2017 11:14 a.m.To: thi...@macieira.orgCc: subsurface@subsurface-divelog.orgSubject: Re: anyone with a Mac running 10.7 or 10.8? On 01 Jan 2017, at 14:07, Robert Hellingwrote:that was quick: Xcode requires at least 10.11.5 … and home-brew also requires Xcode command line tools…Any idea how I could install a debugger?BestRobert___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: anyone with a Mac running 10.7 or 10.8?
Em domingo, 1 de janeiro de 2017, às 12:52:50 BRST, Robert Helling escreveu: > From the command line it's the same, it crashes with "Illegal instruction:4" Any chance you can get the backtrace or disassembly of the crashing instruction? This rings a bell of a problem we had way in the past when some code had AVX instructions, which would cause it to run on hardware pre-2011. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: anyone with a Mac running 10.7 or 10.8?
Em sábado, 31 de dezembro de 2016, às 20:29:10 BRST, Dirk Hohndel escreveu: > From looking through the Subsurface cloud server logs I can see that we > still have a fair number of users on MacOS 10.7 and 10.8. I went through > the effort to create a DMG that should run even on 10.7. I'd love it if > someone could verify that this actually works. > > http://subsurface-divelog.org/downloads/daily/Subsurface-4.5.96-36-ge94d4966 > 8ef9-10.7.dmg > > The regular DMG should run on 10.9 and newer (it would also be useful to > verify that this does, indeed, run on 10.9 and doesn't run on 10.7 or > 10.8). I have a 10.9 VM in the office, so I can test it in a week's time. Unfortunately, it didn't occur to me to create VMs from the recovery images until after I had upgraded from 10.8 to 10.9, so I can't test 10.8. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface