Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[coroberti .]

On Fri, Jun 21, 2019 at 9:42 AM Hamish Moffatt
 wrote:
>
> Apple says that all apps will need to be notarized (viewed) by them to
> be run on macOS 10.15 once released.
> Apps must have the hardened runtime enabled in Xcode before they can be
> notarized.
> Is there any way to get qmake to enable that project option?
> Hamish
>
Hi Hamish,
Good catch. Thanks for the reminder of notarization - a one more
headache from Apple.
Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Kai Köhne]

> -Original Message-
> From: Interest  On Behalf Of Hamish
> Moffatt
> Sent: Friday, June 21, 2019 8:42 AM
> To: Qt Interest 
> Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> 
> Apple says that all apps will need to be notarized (viewed) by them to be run
> on macOS 10.15 once released.
> 
> Apps must have the hardened runtime enabled in Xcode before they can be
> notarized.
> 
> Is there any way to get qmake to enable that project option?

I understand that the "hardened runtime" enabling happens at codesign time,
so this should arguably be a feature of macdeployqt. It's not there yet though,
at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If you're
right that this will become mandatory for macOS 10.15, it arguably get a higher 
priority; feel free to comment, including a link to the source of this 
statement.

For the time being, it seems you've to execute the codesign call yourself.

Regards

Kai
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den fre 21 juni 2019 09:13Kai Köhne  skrev:

> > -Original Message-
> > From: Interest  On Behalf Of Hamish
> > Moffatt
> > Sent: Friday, June 21, 2019 8:42 AM
> > To: Qt Interest 
> > Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> >
> > Apple says that all apps will need to be notarized (viewed) by them to
> be run
> > on macOS 10.15 once released.
> >
> > Apps must have the hardened runtime enabled in Xcode before they can be
> > notarized.
> >
> > Is there any way to get qmake to enable that project option?
>
> I understand that the "hardened runtime" enabling happens at codesign time,
> so this should arguably be a feature of macdeployqt. It's not there yet
> though,
> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If
> you're
> right that this will become mandatory for macOS 10.15, it arguably get a
> higher
> priority; feel free to comment, including a link to the source of this
> statement.
>
> For the time being, it seems you've to execute the codesign call yourself.
>

This is what I've done at work to prepare our builds for this. We use CMake
though and we're already running codesign manually.

The notarization is annoying and takes around 5 minutes for Apple to run
their virus scanners or whatever they're doing, so at the moment we're
doing it only on Git-tagged CI builds (releases), not on every commit. What
this gives us currently is that the macOS "do you want to run this" prompt
will say "Was scanned by Apple on blah blah and found to look good" or
something.

Will be more annoying if/when macOS starts to demand notarized builds,
because then we'd need to do notarization of every commit, or force testers
that wants to test a random build to turn off that checking (which I assume
is still going to be possible through System Preferences).

Apple, sigh, I can understand and sympathize requiring signed builds, but
this mandatory "virus scanned by Apple" is a little silly. As a user I
trust the virus scanner I pick myself more than some blackbox process on
Apple HQ servers.

Elvis


> Regards
>
> Kai
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Michael Jackson]

From: Interest  on behalf of Elvis Stansvik 

Date: Friday, June 21, 2019 at 7:14 AM
To: Kai Köhne 
Cc: Qt Interest 
Subject: Re: [Interest] notarizing builds for Mac - enabling hardened runtime

 

Den fre 21 juni 2019 09:13Kai Köhne  skrev:

> -Original Message-
> From: Interest  On Behalf Of Hamish
> Moffatt
> Sent: Friday, June 21, 2019 8:42 AM
> To: Qt Interest 
> Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> 
> Apple says that all apps will need to be notarized (viewed) by them to be run
> on macOS 10.15 once released.
> 
> Apps must have the hardened runtime enabled in Xcode before they can be
> notarized.
> 
> Is there any way to get qmake to enable that project option?

I understand that the "hardened runtime" enabling happens at codesign time,
so this should arguably be a feature of macdeployqt. It's not there yet though,
at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If you're
right that this will become mandatory for macOS 10.15, it arguably get a higher 
priority; feel free to comment, including a link to the source of this 
statement.

For the time being, it seems you've to execute the codesign call yourself.

 

This is what I've done at work to prepare our builds for this. We use CMake 
though and we're already running codesign manually.

 

The notarization is annoying and takes around 5 minutes for Apple to run their 
virus scanners or whatever they're doing, so at the moment we're doing it only 
on Git-tagged CI builds (releases), not on every commit. What this gives us 
currently is that the macOS "do you want to run this" prompt will say "Was 
scanned by Apple on blah blah and found to look good" or something.

 

Will be more annoying if/when macOS starts to demand notarized builds, because 
then we'd need to do notarization of every commit, or force testers that wants 
to test a random build to turn off that checking (which I assume is still going 
to be possible through System Preferences).

 

Apple, sigh, I can understand and sympathize requiring signed builds, but this 
mandatory "virus scanned by Apple" is a little silly. As a user I trust the 
virus scanner I pick myself more than some blackbox process on Apple HQ servers.

 

Elvis

 


Regards

Kai

 

 

My guess is that macOS will allow you to “override” the need to have the app 
scanned just like you can do now by right-clicking the app and clicking “open”. 
They would have to or developers wouldn’t be able to run their own apps or 
testers wouldn’t be able to run test apps. I don’t think macOS has gone the 
full “App Store Only” model yet, those days are coming. Still it would be good 
to get a definitive answer through Apple docs as to whether Notarization is 
mandatory or just strongly encouraged.

 

--

Mike Jackson

 

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Konstantin Tokarev]

21.06.2019, 16:36, "Michael Jackson" :
> Apple, sigh, I can understand and sympathize requiring signed builds, but 
> this mandatory "virus scanned by Apple" is a little silly. As a user I trust 
> the virus scanner I pick myself more than some blackbox process on Apple HQ 
> servers.

To be fair, it's not about protection of your system, but about protection of 
AppStore users and reputation of Apple as a company. For protection of your 
system you are free in choice of tools.


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Problem with cv::Mat grayscale to QImage

[Jason H]

That indeed seems to be the case. But this is very interesting for Grayscale. RGB888 is fine. Maybe this is more a OpenCV question, why would the BPL not equal pixels per line?

 

Many thanks to all who replied.

 

Sent: Thursday, June 20, 2019 at 5:33 PM
From: "René Hansen" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage


You might need to set the bytesPerLine of the QImage to match the step of cv::Mat. I seem to recall having a similar issue once, converting between a four and three bytes per pixel formats, e.g. if the cv::Mat is in CV_8UC4.
 

 

/René

 


On Thu, 20 Jun 2019 at 23:05, Jason H  wrote:

Simple code:

cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
cv::imwrite("dummy_gray_cv.png", left_image); // ok
QImage test((unsigned char*) left_image.data, left_image.cols, left_image.rows, QImage::Format_Grayscale8);
test.save("dummy_gray_qt.png"); // skewed


However the dummy_gray_qt.png image is not aligned correctly, it's skewed as if bytes are missing/being skipped.

I have to convert it back to color to work:
cv::Mat dst;
cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows, QImage::Format_RGB32);
result.save("dummy_color_qt.png")

Is there a way I can avoid needing cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA)?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

 

 
--

Never fear, Linux is here.




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Problem with cv::Mat grayscale to QImage

[Jason H]

It seems that there is some word/dword/byte-alignment magic going on and the skew is proportional to that. 
 

Sent: Friday, June 21, 2019 at 9:40 AM
From: "Jason H" 
To: "René Hansen" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage




That indeed seems to be the case. But this is very interesting for Grayscale. RGB888 is fine. Maybe this is more a OpenCV question, why would the BPL not equal pixels per line?

 

Many thanks to all who replied.

 

Sent: Thursday, June 20, 2019 at 5:33 PM
From: "René Hansen" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage


You might need to set the bytesPerLine of the QImage to match the step of cv::Mat. I seem to recall having a similar issue once, converting between a four and three bytes per pixel formats, e.g. if the cv::Mat is in CV_8UC4.
 

 

/René

 


On Thu, 20 Jun 2019 at 23:05, Jason H  wrote:

Simple code:

cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
cv::imwrite("dummy_gray_cv.png", left_image); // ok
QImage test((unsigned char*) left_image.data, left_image.cols, left_image.rows, QImage::Format_Grayscale8);
test.save("dummy_gray_qt.png"); // skewed


However the dummy_gray_qt.png image is not aligned correctly, it's skewed as if bytes are missing/being skipped.

I have to convert it back to color to work:
cv::Mat dst;
cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows, QImage::Format_RGB32);
result.save("dummy_color_qt.png")

Is there a way I can avoid needing cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA)?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

 

 
--

Never fear, Linux is here.





___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Problem with cv::Mat grayscale to QImage

[Allan Jensen]

On Friday, 21 June 2019 15:52:55 CEST Jason H wrote:
> It seems that there is some word/dword/byte-alignment magic going on and the
> skew is proportional to that.  

Yes, scan-lines are 32bit aligned. So for non-32bit images we add padding to 
each line to make them align.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den fre 21 juni 2019 15:39Konstantin Tokarev  skrev:

>
>
> 21.06.2019, 16:36, "Michael Jackson" :
> > Apple, sigh, I can understand and sympathize requiring signed builds,
> but this mandatory "virus scanned by Apple" is a little silly. As a user I
> trust the virus scanner I pick myself more than some blackbox process on
> Apple HQ servers.
>
> To be fair, it's not about protection of your system, but about protection
> of AppStore users and reputation of Apple as a company. For protection of
> your system you are free in choice of tools.
>

Yes, I guess so. It's just a little awkward so I guess I was just venting
some frustration :)

We are not publishing to AppStore BTW, but distributing .dmg to clients
ourself.

Elvis


>
> --
> Regards,
> Konstantin
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den fre 21 juni 2019 15:33Michael Jackson 
skrev:

> *From: *Interest  on behalf of Elvis
> Stansvik 
> *Date: *Friday, June 21, 2019 at 7:14 AM
> *To: *Kai Köhne 
> *Cc: *Qt Interest 
> *Subject: *Re: [Interest] notarizing builds for Mac - enabling hardened
> runtime
>
>
>
> Den fre 21 juni 2019 09:13Kai Köhne  skrev:
>
> > -Original Message-
> > From: Interest  On Behalf Of Hamish
> > Moffatt
> > Sent: Friday, June 21, 2019 8:42 AM
> > To: Qt Interest 
> > Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> >
> > Apple says that all apps will need to be notarized (viewed) by them to
> be run
> > on macOS 10.15 once released.
> >
> > Apps must have the hardened runtime enabled in Xcode before they can be
> > notarized.
> >
> > Is there any way to get qmake to enable that project option?
>
> I understand that the "hardened runtime" enabling happens at codesign time,
> so this should arguably be a feature of macdeployqt. It's not there yet
> though,
> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If
> you're
> right that this will become mandatory for macOS 10.15, it arguably get a
> higher
> priority; feel free to comment, including a link to the source of this
> statement.
>
> For the time being, it seems you've to execute the codesign call yourself.
>
>
>
> This is what I've done at work to prepare our builds for this. We use
> CMake though and we're already running codesign manually.
>
>
>
> The notarization is annoying and takes around 5 minutes for Apple to run
> their virus scanners or whatever they're doing, so at the moment we're
> doing it only on Git-tagged CI builds (releases), not on every commit. What
> this gives us currently is that the macOS "do you want to run this" prompt
> will say "Was scanned by Apple on blah blah and found to look good" or
> something.
>
>
>
> Will be more annoying if/when macOS starts to demand notarized builds,
> because then we'd need to do notarization of every commit, or force testers
> that wants to test a random build to turn off that checking (which I assume
> is still going to be possible through System Preferences).
>
>
>
> Apple, sigh, I can understand and sympathize requiring signed builds, but
> this mandatory "virus scanned by Apple" is a little silly. As a user I
> trust the virus scanner I pick myself more than some blackbox process on
> Apple HQ servers.
>
>
>
> Elvis
>
>
>
>
> Regards
>
> Kai
>
>
>
>
>
> My guess is that macOS will allow you to “override” the need to have the
> app scanned just like you can do now by right-clicking the app and clicking
> “open”. They would have to or
>

Yes, I guess so. And I guess that is what we'll ask of our beta testers
(who regularly pull random builds to try out new features under
development) to do, since having to notarize each commit is a bit much. I
guess Apple will discourage such behavior anyway, considering the load it
would put on their infra if everyone did so.

Elvis

developers wouldn’t be able to run their own apps or testers wouldn’t be
> able to run test apps. I don’t think macOS has gone the full “App Store
> Only” model yet, those days are coming. Still it would be good to get a
> definitive answer through Apple docs as to whether Notarization is
> mandatory or just strongly encouraged.
>
>
>
> --
>
> Mike Jackson
>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Accessibility - Different output to braille display and speech?

[SM Clarke]

Is it possible to write a Qt application which passes two strings to a
screenreader (I'm using NVDA), such that the first string is what is
displayed on a Braille display, and the second string is spoken.

The reason is that I have a calendar application, with entries on the
screen in the form: "29 Aug 12:00 - 13:00 : Appointment", and I'd like to
see that visually on the screen and also on the braille display, but I'd
like the screen reader to speak "29th of August, 12pm to 1pm".

In this case, the string is in a QListView, and I've extended the Model to
manage and provide responses to the Qt::DsiplayRole and
Qt::AccessibleTextRole - see snippet below.


QVariant AccessibleStringListModel::data(const QModelIndex &index, int
role) const
>
> {
>
> int row = index.row() ;
>
> if (row<0 || row>=modeldata.size()) return QVariant() ;
>
> const QList& selected = modeldata.at(row) ;
>
> switch (role){
>
> case Qt::DisplayRole:
>
> return selected.at(0) ;
>
> break ;
>
> case Qt::AccessibleTextRole:
>
> return selected.at(1) ;
>
> break ;
>
> //case Qt::UserRole:
>
> //return selected.at(2) ;
>
> //break ;
>
> default: return QVariant() ;
>
> }
>
> }
>
>
The QListView correctly uses the DisplayRole to show the 'selected.at(0)'
on the screen.
It also uses the AccessibleTextRole to speak the 'selected.at(1)'.
But also uses the AccessibleTextRole for the output on the braille display.
Note: I realise that the UserRole has nothing to do with the screen /
display output.

I've also tried using the AccessibleDescriptionRole - this sends the same
output to the Braille display and speech, so doesn't help.

*Q: Is there a way to override the text used for speech such that the
Braille display and speech output are different?*

Thanks and Regards,

Steve C
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Patrick Stinson]

(NOTE: I have started a new thread about this from an old one incorrectly 
associating this problem with “make -jn”)

I am having a hard time pinning down the source of this error. I am getting it 
sporadically on Qt-5.12.0 - Qt-5.13.0. using make -jn flags or not using make 
-jn flags doesn’t seem to have an effect. Any ideas?



/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
 -c -include.pch/Qt5Core/c++_x86_64 -pipe -stdlib=libc++ -O3 -fPIC -std=c++1y 
-fapplication-extension  -arch x86_64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
 -mmacosx-version-min=10.12 -fvisibility=hidden -fvisibility-inlines-hidden 
-ffunction-sections -fdata-sections -Wall -W -Wobjc-interface-ivars 
-Wobjc-method-access -Wobjc-multiple-method-names -DQT_NO_USING_NAMESPACE 
-DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB 
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT 
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS 
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -D_LARGEFILE64_SOURCE 
-D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DPCRE2_CODE_UNIT_WIDTH=16 -I. 
-I../3rdparty/zlib/src -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 
-I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty 
-I../3rdparty/double-conversion/include 
-I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd 
-I../3rdparty/tinycbor/src -I../../include -I../../include/QtCore 
-I../../include/QtCore/5.13.0 -I../../include/QtCore/5.13.0/QtCore -I.moc 
-I.tracegen -I../3rdparty/pcre2/src 
-I/Users/patrick/dev/vendor/sysroot-masos-64/include -I../../mkspecs/macx-clang 
-o .obj/qatomic.o thread/qatomic.cpp
thread/qatomic.cpp:1624:4: error: "Q_ATOMIC_INT64_IS_SUPPORTED must be defined 
on a 64-bit platform"
#  error "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
   ^
In file included from thread/qatomic.cpp:1:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/global/qt_pch.h:56:
In file included from 
../../include/QtCore/../../src/corelib/global/qglobal.h:1224:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/qatomic.h:1:
In file included from thread/qatomic.h:46:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/qbasicatomic.h:1:
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5:
 error: static_assert failed due to requirement 
'bool(QAtomicOpsSupport::IsSupported)' "template parameter is an 
integral of a size not supported on this platform"
Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupported, "template 
parameter is an integral of a size not supported on this platform");

^~
../../include/QtCore/../../src/corelib/global/qglobal.h:121:49: note: expanded 
from macro 'Q_STATIC_ASSERT_X'
#  define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), 
Message)
^ ~~~
thread/qatomic.h:55:31: note: in instantiation of template class 
'QBasicAtomicInteger' requested here
class QAtomicInteger : public QBasicAtomicInteger
  ^
thread/qatomic.cpp:1631:17: note: in instantiation of template class 
'QAtomicInteger' requested here
Q_STATIC_ASSERT(sizeof(QAtomicInteger));
^
In file included from thread/qatomic.cpp:1:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/global/qt_pch.h:56:
In file included from 
../../include/QtCore/../../src/corelib/global/qglobal.h:1224:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/qatomic.h:1:
In file included from thread/qatomic.h:46:
In file included from 
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/qbasicatomic.h:1:
/Users/patrick/dev/vendor/sysroot-masos-64/build/qt-everywhere-src-5.13.0/qtbase/src/corelib/../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5:
 error: static_assert failed due to requirement 
'bool(QAtomicOpsSupport::IsSupported)' "template 
parameter is an integral of a size not supported on this platform"
Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupported, "template 
parameter is an integral of a size not supported on this platform");

^~

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Thiago Macieira]

On Friday, 21 June 2019 10:00:45 PDT Patrick Stinson wrote:
> thread/qatomic.cpp:1624:4: error: "Q_ATOMIC_INT64_IS_SUPPORTED must be
> defined on a 64-bit platform"

The macro is defined by this block in qatomic_cxx11.h:

#if QT_CONFIG(std_atomic64)
template<> struct QAtomicOpsSupport<8> { enum { IsSupported = 1 }; };
#  define Q_ATOMIC_INT64_IS_SUPPORTED

So the question is whether QT_FEATURE_std_atomic64 is defined to 1 or not. Can 
you open the src/corelib/qtcore-config.h in the build dir and see if it is 
there?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Patrick Stinson]

#define QT_FEATURE_std_atomic64 -1

> On Jun 21, 2019, at 9:32 AM, Thiago Macieira  
> wrote:
> 
>  src/corelib/qtcore-config.h

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Jean-Michaël Celerier]

Every time I had this error recently it's because I cleaned my build
directory via rm -rf * which did not remove the hidden .qmake.cache files
in there which then thoroughly destroys any attemptto rebuild qt in this
directory.

Maybe it can help ? (it was the exact same symptoms in any case)
Best,
Jean-Michaël

On Fri, Jun 21, 2019 at 7:37 PM Patrick Stinson 
wrote:

> #define QT_FEATURE_std_atomic64 -1
>
> On Jun 21, 2019, at 9:32 AM, Thiago Macieira 
> wrote:
>
>  src/corelib/qtcore-config.h
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Thiago Macieira]

On Friday, 21 June 2019 10:35:36 PDT Patrick Stinson wrote:
> #define QT_FEATURE_std_atomic64 -1

Can you check the config.log in the top-level dir to see what how the std-
atomic64 test failed? If you don't see that in the config.log, remove 
config.cache and rerun configure (./config.status)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Hamish Moffatt]

On 21/6/19 9:13 pm, Elvis Stansvik wrote:
Den fre 21 juni 2019 09:13Kai Köhne > skrev:



For the time being, it seems you've to execute the codesign call
yourself.


This is what I've done at work to prepare our builds for this. We use 
CMake though and we're already running codesign manually.


Great, we are already running codesign ourselves (as we add some other 
frameworks post-macdeployqt), so adding the extra parameter is no big deal.





The notarization is annoying and takes around 5 minutes for Apple to 
run their virus scanners or whatever they're doing, so at the moment 
we're doing it only on Git-tagged CI builds (releases), not on every 
commit. What this gives us currently is that the macOS "do you want to 
run this" prompt will say "Was scanned by Apple on blah blah and found 
to look good" or something.


Will be more annoying if/when macOS starts to demand notarized builds, 
because then we'd need to do notarization of every commit, or force 
testers that wants to test a random build to turn off that checking 
(which I assume is still going to be possible through System Preferences).



https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution 
says that it will be required on 10.15. Hopefully this will be easy to 
disable for our testers as we don't want to notarize the daily builds. 
Otherwise are uploading half a Gb of packages and then waiting for them 
to be checked each time.


Do you know if it's sufficient to notarize the final .dmg or .pkg, or do 
you have to separately notarize and staple the .app before it is 
packaged? I haven't been able to find a good answer yet. But the Apple 
check is complaining about files inside my .app inside my .pkg, so I 
guess it will be sufficient to do the final .pkg.



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Patrick Stinson]

My config.log did not contain the string “std-atomic64.” It did report that it 
could not find libatomic. Deleting config.cache and running config.status 
worked though!

So how do you account for that? Seems very odd to me. This was from a freshly 
extracted qt source archive.

> On Jun 21, 2019, at 12:13 PM, Thiago Macieira  
> wrote:
> 
> On Friday, 21 June 2019 10:35:36 PDT Patrick Stinson wrote:
>> #define QT_FEATURE_std_atomic64 -1
> 
> Can you check the config.log in the top-level dir to see what how the std-
> atomic64 test failed? If you don't see that in the config.log, remove 
> config.cache and rerun configure (./config.status)
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS

[Patrick Stinson]

I am building qt from a couple of different scripts so it would be great to be 
able to have them work on first run.

> On Jun 21, 2019, at 8:50 PM, Patrick Stinson  wrote:
> 
> My config.log did not contain the string “std-atomic64.” It did report that 
> it could not find libatomic. Deleting config.cache and running config.status 
> worked though!
> 
> So how do you account for that? Seems very odd to me. This was from a freshly 
> extracted qt source archive.
> 
>> On Jun 21, 2019, at 12:13 PM, Thiago Macieira  
>> wrote:
>> 
>> On Friday, 21 June 2019 10:35:36 PDT Patrick Stinson wrote:
>>> #define QT_FEATURE_std_atomic64 -1
>> 
>> Can you check the config.log in the top-level dir to see what how the std-
>> atomic64 test failed? If you don't see that in the config.log, remove 
>> config.cache and rerun configure (./config.status)
>> 
>> -- 
>> Thiago Macieira - thiago.macieira (AT) intel.com
>> Software Architect - Intel System Software Products
>> 
>> 
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest