[Interest] update on building Qt/Linux with clang?
Colin Worth
jlk2144 at gmail.com
Tue Nov 6 04:09:37 CET 2018
There is a warning in the OS X part of the build instructions (OS X builds with clang) not to do a parallel build (-J > 1) due to competing dependencies.
> On Nov 5, 2018, at 2:32 PM, interest-request at qt-project.org wrote:
>
> Send Interest mailing list submissions to
> interest at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.qt-project.org/mailman/listinfo/interest
> or, via email, send a message with subject or body 'help' to
> interest-request at qt-project.org
>
> You can reach the person managing the list at
> interest-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Interest digest..."
> Today's Topics:
>
> 1. Re: Chasing a standard (roland at logikalsolutions.com)
> 2. Re: Chasing a standard (roland at logikalsolutions.com)
> 3. Re: Interest Digest, Vol 86, Issue 5 (roland at logikalsolutions.com)
> 4. Re: Chasing a standard (Jason H)
> 5. Re: update on building Qt/Linux with clang?
> (Allan Sandfeld Jensen)
> 6. Re: update on building Qt/Linux with clang?
> (Allan Sandfeld Jensen)
> 7. Re: update on building Qt/Linux with clang?
> (Jean-Micha?l Celerier)
> 8. Re: Chasing a standard (roland at logikalsolutions.com)
> 9. Re: update on building Qt/Linux with clang?
> (william.crocker at analog.com)
> 10. Re: Chasing a standard (J?r?me Godbout)
> 11. Re: Chasing a standard (roland at logikalsolutions.com)
> 12. Re: Chasing a standard (J?r?me Godbout)
> 13. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA
> encrypt) (Thiago Macieira)
> 14. Re: update on building Qt/Linux with clang? (Thiago Macieira)
> 15. Re: Interest Digest, Vol 86, Issue 5 (Giuseppe D'Angelo)
> 16. Re: update on building Qt/Linux with clang? (Ren? J.V. Bertin)
> 17. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA
> encrypt) (ekke)
>
> From: roland at logikalsolutions.com
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 9:39:38 AM EST
> To: Tomasz Siekierda <sierdzio at gmail.com>
> Cc: lars.knoll at qt.io, interest at qt-project.org
>
>
>
> Quoting Tomasz Siekierda <sierdzio at gmail.com>:
>
>> On Mon, 5 Nov 2018 at 13:35, Roland Hughes <roland at logikalsolutions.com> wrote:
>>>
>>>
>>> On 11/4/18 3:52 PM, Lars Knoll wrote:
>>> >> On 4 Nov 2018, at 22:13, Roland Hughes <roland at logikalsolutions.com> wrote:
>>> >>
>>> >>
>>> >> We already lose droves of Qt developers every year when Qt keeps moving on but medical devices, border security systems like cargo x-ray, train control systems, etc. have to fork their own version of Qt because Qt keeps moving on without a 5-8 year LTS.
>>> > Yes, the Open source and standard commercial versions come with a maximum of 3 years for LTS releases. But you can get longer support for Qt versions from The Qt Company though.
>>>
>>> Three years isn't a drop of water in Lake Michigan. A completely new
>>> surgical robot will take a minimum of 4 years design and prototyping
>>> followed by 1-3 years of development (which must also include the
>>> _entire_ manufacturing process for certification.) Then it goes through
>>> clinical trials which can last upwards of 7 years. Once released to the
>>> field it will be in maintenance/minor enhancement mode for 10 years or
>>> more. This entire time the tool set must be locked down.
>>
>> Since the tool is locked down, then it does not matter if Qt has moved
>> on or not, right? You're not allowed to upgrade/ change it anyway, you
>> have to stick to what you deployed. So there is no reason to complain
>> about lack of support here. That's the reality of such big and long
>> term projects. NASA also still keeps operational their computers from
>> 1970 to handle Voyager missions. It does not mean that the
>> manufacturers of these PC are somehow obligated to support them
>> anymore.
>
>
> This would be a gross missunderstanding of how the FDA "lockdown" is actually applied. Minor bug fixes can have documentation generated via an FDA approved process with dramatically reduced testing cycle since it is mostly negative testing. (Negative testing being testing no changes to other existing functionality.) The definition of "minor" is totally within the purview of the FDA and argued case by case.
>
> As far as manufacturers and obligations, see below.
>
>>
>>> Just this year a drug manufacturer in California fielded a job opening
>>> looking for a PDP-11 systems manager familiar with hardware maintenance.
>>> Some of you may recall that a PDP-11 was the machine C and UNIX were
>>> developed on in the 1970s. It was _the_ midrange computer of its day but
>>> hasn't been manufactured since the late 1980s.
>>
>> And you bring this up because PDP-11 is still supported by its
>> (non-existing by since 20 years) manufacturer just like Qt should?
>
> There are quite a few places still providing support for the PDP-11 line. Quite a few companies stock piled 11/24 and 11/44 machines as others moved to VAX, ALPHA, and ITANIUM. Ownership of the line moved from DEC to Compaq to HP.
>
> Shortly after Compaq consumed Digital Equipment Corporation, Microsoft paid them a bunch of money to announce the death of OpenVMS in a bid to get feeble Windows servers running on Compaq PCs into data centers where they were previously barred. Some corporations started to make the move. The NSA and DOD paid Compaq a Microsoft a visit. They showed them the sales and support contracts making cessation of the platform an act of treason and informed the leaders of both companies just how lengthy their prison time would be. You see, Bill Gates could bribe Bill and Hillary Clinton to make the Janet Reno investigation go in a "don't put Bill in prison for wire and mail fraud" direction, but the DOD and NSA weren't smiling and given their budgets, no interested in any bribe either company could offer.
>
> Compaq then announced they weren't killing off OpenVMS and Bill Gates stepped out of the go-to-prison hot seat as part of the apology. The other details I do not know. I do know there was much more than that involved.
>
> NASA had, and probably still has similar contracts.
>
> These long term support contracts are why we have $12 wooden pencils and $800 hammers. That __EXACT__ product has to remain available and replacable for many many decades. Even if every tree of that type dies on the planet, the vendor who signed the contract must still find a way to make that __EXACT__ pencil with that __EXACT__ wood and other components. There is still a vendor prodiving 8 inch floppies to the DOD because they are used to boot the nuclear missile launch systems. Given the short life of floppies, they aren' surviving on a eBay stockpile. They are actually making them every so often.
>
> If Qt wishes to play in the embedded world, it has to come to grips with this reality. It's not a "chase the latest idiot phone trend" world. This is why you are starting to see various companies who would otherwise consider each other competitors banding together to maintain the now abandoned Qt releases. Most every year or at least every other year I get emails and calls about doing Qt 3 work on OS/2 from this Harman (sp?) consulting firm. Minor changes to an existing medical device whose systems were built using those tools.
>
> One of my past clients had almost nothing to do with the DOD post WW-II, but, they still have all of the equipment to make torpedos for said boats and ships. They must keep it on site in good condition until the contract ends. I've been told that contract doesn't end until the last vessel of war capabile of firing said munitions is scuttled. I have not personally seen the contract, nor do I wish to. You will find every major manufacturer which existed during WW-II has a similar contract for something else. These contracts don't expire until the DOD deems what they manufactured non-strategic and disposes of it.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
>
> From: roland at logikalsolutions.com
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 9:42:36 AM EST
> To: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>
> Cc: Lars Knoll <lars.knoll at qt.io>, interest <interest at qt-project.org>
>
>
>
> Quoting Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>:
>
>>> As I said a couple of times, we do not intend to break APIs in any major
>> way when moving towards Qt 6. That also implies that our container API is
>> there to stay. But where we can streamline/align with standard C++ in good
>> ways, we probably should try to do that.
>>
>> It's not only about breaking APIs but also breaking current observable
>> behaviour - i.e. performance. Currently if you're passing data across
>> threads - e.g. compute something in a thread and pass the result to the
>> main thread to display it - you generally pass a QVector / QList /
>> QWhatever that does implicit sharing, because the signal-slot mechanism
>> will do a copy of the object in any case across threads and doing two
>> atomic operations for a QVector copy is cheaper than creating a new
>> std::vector, calling malloc, and copying 500 ints however you look at it.
>> What is the option if Qt opts out from this ? put everything in shared_ptr
>> ?
>
> Very good catch.
>
> Battery powered embedded systems in the medical and industrial world have wretched dynamic memory allocation. If the underlying implementation does away with shallow/no-copy passing between threads for some std:: version which requires giahugic (given 512 MEG total working RAM) data sets with sluggish allocation (if enough memory exists at all) this is an extreme price.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
>
> From: roland at logikalsolutions.com
> Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5
> Date: November 5, 2018 at 10:07:04 AM EST
> To: interest at qt-project.org
>
>
>
> Quoting Giuseppe D'Angelo:
>
> ====
> Hold on -- I don't think that anyone wants to make Qt containers NOT
> implictly shared. In other words, Qt 6 containers will be implictly
> shared just as today. It would be a gigantic break if we suddenly made
> them not shared.
> ====
>
> Well, there have been others on this list making statements about Qt no longer investing effort to do things std:: already does. I myself earlier this year was involved with an exchange where someone was telling people to use std::vector becase QVector was deprecated going forward.
>
> That definitely would be a gigantic break.
>
> Switching the containers to just be wrappers around std:: implementations would also be a dramatic break.
>
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
>
> From: "Jason H" <jhihn at gmx.com>
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 10:13:00 AM EST
> To: roland at logikalsolutions.com
> Cc: "Jean-Michaël Celerier" <jeanmichael.celerier at gmail.com>, interest <interest at qt-project.org>
>
>
>
>
>> Sent: Monday, November 05, 2018 at 9:42 AM
>> From: roland at logikalsolutions.com
>> To: "Jean-Michaël Celerier" <jeanmichael.celerier at gmail.com>
>> Cc: interest <interest at qt-project.org>
>> Subject: Re: [Interest] Chasing a standard
>>
>>
>> Quoting Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>:
>>
>>>> As I said a couple of times, we do not intend to break APIs in any major
>>> way when moving towards Qt 6. That also implies that our container API is
>>> there to stay. But where we can streamline/align with standard C++ in good
>>> ways, we probably should try to do that.
>>>
>>> It's not only about breaking APIs but also breaking current observable
>>> behaviour - i.e. performance. Currently if you're passing data across
>>> threads - e.g. compute something in a thread and pass the result to the
>>> main thread to display it - you generally pass a QVector / QList /
>>> QWhatever that does implicit sharing, because the signal-slot mechanism
>>> will do a copy of the object in any case across threads and doing two
>>> atomic operations for a QVector copy is cheaper than creating a new
>>> std::vector, calling malloc, and copying 500 ints however you look at it.
>>> What is the option if Qt opts out from this ? put everything in shared_ptr
>>> ?
>>
>> Very good catch.
>>
>> Battery powered embedded systems in the medical and industrial world
>> have wretched dynamic memory allocation. If the underlying
>> implementation does away with shallow/no-copy passing between threads
>> for some std:: version which requires giahugic (given 512 MEG total
>> working RAM) data sets with sluggish allocation (if enough memory
>> exists at all) this is an extreme price.
>
> Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
> ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))
>
> I've also attributed failures on long-running commodity hardware (RaspberryPis) to the memory fragmentation issue of dynamic memory. Interestingly, this is why other languages (C#, Java) have dynamic memory consolidation capability (i.e. Mark & Sweep, "Handles" (^) in the .NET C++ CLR). But as the JPL standard shows, you do not need to create non-deterministic garbage collection in your language. While I attributed this to failures on a Pi, I have actually researched and concluded that this indeed was the case on an embedded application on a PPC 860. Removing dynamic memory and reverting to fixed-arrays eliminated the crashes after months of run-time. Unfortunately this is nearly impossible on a Pi with it's much larger software ecosystem.
>
>
>
>
>
>
>
> From: Allan Sandfeld Jensen <kde at carewolf.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 10:34:31 AM EST
> To: interest at qt-project.org
> Cc: René J.V. Bertin <rjvbertin at gmail.com>
>
>
> On Montag, 5. November 2018 12:03:31 CET René J.V. Bertin wrote:
>> Hi,
>>
>> Last time I asked the advice was still not to bother with trying to build
>> (all of) Qt with clang on Linux. Is that still the case or is it now safe
>> to use clang (5 or 6)?
>>
>> In my experience clang generates significantly more compact binaries, which
>> should reduce load times. Build time should be shorter too.
>>
> I build all of Qt regularly with clang to make sure qtwebengine works like
> that, and I have never had any issues. You can even use clang-libc++ if you
> make sure not to depend on any system C++ libraries.
>
> 'Allan
>
>
>
>
>
>
> From: Allan Sandfeld Jensen <kde at carewolf.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 10:38:04 AM EST
> To: interest at qt-project.org
> Cc: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>, René J.V. <rjvbertin at gmail.com>
>
>
> On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
>> I tried building everything with clang 7 and libc++ last week but hit a
>> qlalr segfault during build. I've been trying to debug it ever since to no
>> avail.
>>
>>
> clang sometimes segfaults while compiling, the crash usually goes if I try
> again. It seems to just randomly crash once for every ~10 thousand files
> compiled for no reason. The fact the crashes are random and not stable doesn't
> really raise my confidence in clang code quality though, but it is easy to
> work around. Just keep calling make until it makes it.
>
> 'Allan
>
>
>
>
>
>
> From: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 10:50:10 AM EST
> To: Allan Sandfeld Jensen <kde at carewolf.com>
> Cc: interest <interest at qt-project.org>, René J.V. <rjvbertin at gmail.com>
>
>
> > clang sometimes segfaults while compiling, the crash usually goes if I try
> again.
>
> in my case it's not clang which crashes but the qlalr that clang produces. For some reason it works :
> - when building in debug
> - when building statically
>
> it's just the release / dynamic configuration that crashes, and I don't know how to instruct Qt's configure to keep debug symbols for release builds of the tools in order to get a proper stacktrace.
>
>
> On Mon, Nov 5, 2018 at 4:38 PM Allan Sandfeld Jensen <kde at carewolf.com <mailto:kde at carewolf.com>> wrote:
> On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
> > I tried building everything with clang 7 and libc++ last week but hit a
> > qlalr segfault during build. I've been trying to debug it ever since to no
> > avail.
> >
> >
> clang sometimes segfaults while compiling, the crash usually goes if I try
> again. It seems to just randomly crash once for every ~10 thousand files
> compiled for no reason. The fact the crashes are random and not stable doesn't
> really raise my confidence in clang code quality though, but it is easy to
> work around. Just keep calling make until it makes it.
>
> 'Allan
>
>
>
>
>
> From: roland at logikalsolutions.com
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 10:54:36 AM EST
> To: Jason H <jhihn at gmx.com>
> Cc: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>, interest <interest at qt-project.org>
>
>
>
> Quoting Jason H <jhihn at gmx.com>:
>
>>>
>>> Very good catch.
>>>
>>> Battery powered embedded systems in the medical and industrial world
>>> have wretched dynamic memory allocation. If the underlying
>>> implementation does away with shallow/no-copy passing between threads
>>> for some std:: version which requires giahugic (given 512 MEG total
>>> working RAM) data sets with sluggish allocation (if enough memory
>>> exists at all) this is an extreme price.
>>
>> Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
>> ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))
>>
>
> I've never worked on a single medical device which utilized JPL. Not one. Not saying there isn't one somewhere in the world, but, I've never seen it. One could not use Qt in a medical device if strictly adhering to JPL. Something simple like an error message to syslog being built with a QString would violate such a standard. You couldn't fill in the values with .arg().
>
> No, the container issue in medical device world isn't moot. It's a clear and present danger.
>
>
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
>
> From: "william.crocker at analog.com" <william.crocker at analog.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 10:58:14 AM EST
> To: <interest at qt-project.org>
>
>
> On 11/05/2018 10:38 AM, Allan Sandfeld Jensen wrote:
>> On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
>>> I tried building everything with clang 7 and libc++ last week but hit a
>>> qlalr segfault during build. I've been trying to debug it ever since to no
>>> avail.
>>>
>>>
>> clang sometimes segfaults while compiling, the crash usually goes if I try
>> again. It seems to just randomly crash once for every ~10 thousand files
>> compiled for no reason.
>
> Sounds like a job for valgrind.
>
>> The fact the crashes are random and not stable doesn't
>> really raise my confidence in clang code quality though, but it is easy to
>> work around. Just keep calling make until it makes it.
>>
>> 'Allan
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
>
>
>
>
>
> From: Jérôme Godbout <godboutj at amotus.ca>
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 11:07:36 AM EST
> To: "roland at logikalsolutions.com" <roland at logikalsolutions.com>, Jason H <jhihn at gmx.com>
> Cc: interest <interest at qt-project.org>
>
>
> I did a few medical application for orthopedic surgery, the coding standard is not a requirement, but only a simplest way to validate your software. I did used Qt into all of them and we manage to certify them for surgery room. It always depend on the level or risk your software lies on. Also if you can proof your software is robust enough (yeah it take a lot of testing and safe guard everywhere) you can pass the certification. JPL only make it easier to pass those since you proof in a easy way that it cannot goes wrong, that's about it.
>
> JPL would be a good thing if you were to make a peacemaker for example. It's more for embedded C software where dynamic alloc is not allowed (just like car industries). If you plan on running C++ on a MCU with very limited resource, you are looking for trouble (it's doable, but the tests time will inflate more then what you will save from C to C++) and will need to take very much great care of the object you create and destroy. In other word, it's a bad idea, stick to C for embedded or critical component.
>
> -----Original Message-----
> From: Interest <interest-bounces+godboutj=amotus.ca at qt-project.org> On Behalf Of roland at logikalsolutions.com
> Sent: November 5, 2018 10:55 AM
> To: Jason H <jhihn at gmx.com>
> Cc: interest <interest at qt-project.org>
> Subject: Re: [Interest] Chasing a standard
>
>
> Quoting Jason H <jhihn at gmx.com>:
>
>>>
>>> Very good catch.
>>>
>>> Battery powered embedded systems in the medical and industrial world
>>> have wretched dynamic memory allocation. If the underlying
>>> implementation does away with shallow/no-copy passing between threads
>>> for some std:: version which requires giahugic (given 512 MEG total
>>> working RAM) data sets with sluggish allocation (if enough memory
>>> exists at all) this is an extreme price.
>>
>> Medical and Space-based systems should use the NASA (JPL) coding
>> standard. Chief of which is no dynamic memory after initialization.
>> So all your container arguments are moot.
>> ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of
>> course you're using mysmic memory after initialization in a medical
>> device (But then, WHY!?))
>>
>
> I've never worked on a single medical device which utilized JPL. Not one. Not saying there isn't one somewhere in the world, but, I've never seen it. One could not use Qt in a medical device if strictly adhering to JPL. Something simple like an error message to syslog being built with a QString would violate such a standard. You couldn't fill in the values with .arg().
>
> No, the container issue in medical device world isn't moot. It's a clear and present danger.
>
>
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
>
> From: roland at logikalsolutions.com
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 11:29:54 AM EST
> To: Jérôme Godbout <godboutj at amotus.ca>
> Cc: Jason H <jhihn at gmx.com>, interest <interest at qt-project.org>
>
>
>
> Quoting Jérôme Godbout <godboutj at amotus.ca>:
>
>> JPL would be a good thing if you were to make a peacemaker for example. It's more for embedded C software where dynamic alloc is not allowed (just like car industries). If you plan on running C++ on a
>
> Stupid question, but if dynamic memory allocation is not allowed in the automotive industry, how is it Ford is constantly looking for low wage Qt developers? More a curiosity than anything else. Those contracts pay less than 1/3 of my standard billing rate so the emails and phone calls about them land in the virtual bit bucket.
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
>
> From: Jérôme Godbout <godboutj at amotus.ca>
> Subject: Re: [Interest] Chasing a standard
> Date: November 5, 2018 at 11:43:44 AM EST
> To: "roland at logikalsolutions.com" <roland at logikalsolutions.com>
> Cc: Jason H <jhihn at gmx.com>, interest <interest at qt-project.org>
>
>
> Qt is probably only used into a part of the Dashboard or entertainment system, the controller chip or embedded MCU and other safety controller are probably not using Qt nor C++. They follow some MISRA, AUTOSAR, CERT standard. They have a C++ standard, but seriously it prevent a good chunk of the language usage. Like in the medical, it always on which system critical part your software going to run, the radio with BLE phone that crash is one thing, the wheel control is another matter. If you don't follow those standard (which is possible), the burden of the proof of reliability false on you and you have to prove how your software can NEVER be a life threat.
>
>
> -----Original Message-----
> From: roland at logikalsolutions.com <roland at logikalsolutions.com>
> Sent: November 5, 2018 11:30 AM
> To: Jérôme Godbout <godboutj at amotus.ca>
> Cc: Jason H <jhihn at gmx.com>; interest <interest at qt-project.org>
> Subject: Re: [Interest] Chasing a standard
>
>
> Quoting Jérôme Godbout <godboutj at amotus.ca>:
>
>> JPL would be a good thing if you were to make a peacemaker for
>> example. It's more for embedded C software where dynamic alloc is
>> not allowed (just like car industries). If you plan on running C++
>> on a
>
> Stupid question, but if dynamic memory allocation is not allowed in
> the automotive industry, how is it Ford is constantly looking for low
> wage Qt developers? More a curiosity than anything else. Those
> contracts pay less than 1/3 of my standard billing rate so the emails
> and phone calls about them land in the virtual bit bucket.
> --
> Roland Hughes, President
> Logikal Solutions
> (630) 205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us
>
>
>
>
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA encrypt)
> Date: November 5, 2018 at 11:59:46 AM EST
> To: <interest at qt-project.org>
>
>
> On Monday, 5 November 2018 05:49:33 PST ekke wrote:
>> created a example app and now noticed, the app doesn't freeze,
>> but the exection of encrypt() slows down from
>>
>> 5 sec (Qt 5.11.2) to
>> 92 sec (Qt 5.12 Beta3)
>>
>> will open a bug report
>
> How about you encrypt using C++ instead? OpenSSL probably has the encryption
> you need.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
>
>
>
>
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 12:01:31 PM EST
> To: <interest at qt-project.org>
>
>
> On Monday, 5 November 2018 07:50:10 PST Jean-Michaël Celerier wrote:
>> it's just the release / dynamic configuration that crashes, and I don't
>> know how to instruct Qt's configure to keep debug symbols for release
>> builds of the tools in order to get a proper stacktrace.
>
> Edit the Makefile after generation and add -g to the CXXFLAGS of the relevant
> builds.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
>
>
>
>
> From: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
> Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5
> Date: November 5, 2018 at 12:21:02 PM EST
> To: interest at qt-project.org
>
>
> Hi,
>
> Il 05/11/18 16:07, roland at logikalsolutions.com ha scritto:
>> Switching the containers to just be wrappers around std::
>> implementations would also be a dramatic break.
>
> Assuming by "wrappers" you mean "implicitly shared wrappers", why would it be a break?
>
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
>
>
>
> From: René J.V. Bertin <rjvbertin at gmail.com>
> Subject: Re: [Interest] update on building Qt/Linux with clang?
> Date: November 5, 2018 at 12:55:21 PM EST
> To: Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>
> Cc: Allan Sandfeld Jensen <kde at carewolf.com>, interest <interest at qt-project.org>
>
>
> On Monday November 05 2018 16:50:10 Jean-Michaël Celerier wrote:
>
>> it's just the release / dynamic configuration that crashes, and I don't
>> know how to instruct Qt's configure to keep debug symbols for release
>> builds of the tools in order to get a proper stacktrace.
>
> I use these arguments to configure: -no-strip -no-separate-debug-info --force-debug-info
>
> Or skip the last, and just run `qmake -config force_debug_info /path/to/qtcomponent/qtcomponent.pro` in the build directory for the component(s) you want to have debug info for (useful if you only want it in qtbase).
> Clang apparently also wants -fno-limit-debug-info if you really want to have useful debug info (though I can't tell if it really makes a difference).
>
>>> clang sometimes segfaults while compiling, the crash usually goes if I try
>>> again. It seems to just randomly crash once for every ~10 thousand files
>>> compiled for no reason. The fact the crashes are random and not stable
>>> doesn't
>>> really raise my confidence in clang code quality though, but it is easy to
>>> work around. Just keep calling make until it makes it.
>
> My build with clang just completed fine, of all components except qt3d, qtwebengine and qtwebview. I've not seen clang crash when compiling Qt code on Mac for a long time, but there it uses a fully native libc++ which may make a difference.
>
> I'd expect your build machine is probably much more powerful than mine, but what if those random crashes are due to some sort of resource depletion or contention? That's really the only thing that makes some kind of sense... and I'm almost certain I've already seen MacPorts ports that are built in non-parallel fashion because clang crashes otherwise.
>
> R.
>
>
>
>
> From: ekke <ekke at ekkes-corner.org>
> Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA encrypt)
> Date: November 5, 2018 at 2:32:03 PM EST
> To: interest at qt-project.org
>
>
> Am 05.11.18 um 17:59 schrieb Thiago Macieira:
>> On Monday, 5 November 2018 05:49:33 PST ekke wrote:
>>> created a example app and now noticed, the app doesn't freeze,
>>> but the exection of encrypt() slows down from
>>>
>>> 5 sec (Qt 5.11.2) to
>>> 92 sec (Qt 5.12 Beta3)
>>>
>>> will open a bug report
>> How about you encrypt using C++ instead? OpenSSL probably has the encryption
>> you need.
>>
> Thanks, Thiago for the hint - that was the first thing I tried, but
> couldn't figure out HowTo make it work on Android and iOS.
>
> It's only used when password has changed and must be entered: then
> password must be RSA encrypted and base64 sent to server
>
> so I was happy to find a JS solution which was implemented easy for
> Android / iOS:
>
> function doEncrypt() {
> var rsa = new MyRsa.RSAKey();
> rsa.setPublic(dataServer.modulusHex(), "10001")
> var res = rsa.encrypt(pwText.text)
> if(res) {
> return MyRsa.linebrk(res, 64)
> } else {
> return ""
> }
> }
>
> unfortunately now with 5.12 Beta it slows down by 20x.
>
> on Android per ex. from 80 ms to 1700 ms (acceptable for my customer)
>
> but iOS now is too slow
>
> ekke
>
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181105/0dca9609/attachment.html>
More information about the Interest
mailing list