Re: [Interest] Creating fat binaries for Qt6 on macOS

[Thiago Macieira]

On Tuesday, 12 April 2022 16:32:42 PDT Dirk Hohndel wrote:
> That's exactly what it does. I'm surprised that no one else ran into this,
> though. After all, the Qt distribution binaries are all fat binaries.

Must be a combination of fat binaries and something about the paths 
themselves. The code has a filter:

if (rpaths.contains(resolveDyldPrefix(rpath, binaryPath, binaryPath))) 
{
args << "-delete_rpath" << rpath;
}

I don't know for sure. But, yes, it needs a protection against duplicates.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Interest] Creating fat binaries for Qt6 on macOS

[Dirk Hohndel]

> On Apr 12, 2022, at 06:20, Thiago wrote:
> 
> On Monday, 11 April 2022 23:17:17 PDT Dirk Hohndel wrote:
>>> The error message is talking about how the same path was being removed
>>> more
>>> than once, which means your binary has it twice. I guess this had simply
>>> never occurred in the past. Deduplicating the paths is not a bad idea in
>>> macdeployqt, but you can also investigate why your build arrived at this
>>> point with twice the same rpath and change that.
>> 
>> I will look into this. I'm thinking that this is a result of this being fat
>> binaries with identical rpath in both sides.
> 
> It's possible. The tool is parsing the output of otool -l, so if that prints 
> the rpaths for both members of the fat binary, it would indeed get confused.

That's exactly what it does. I'm surprised that no one else ran into this, 
though.
After all, the Qt distribution binaries are all fat binaries.

Here's an example:

% otool -l Subsurface.app/Contents/MacOS/Subsurface | grep -A2 LC_RPATH
  cmd LC_RPATH
  cmdsize 48
 path /Users/hohndel/src/install-root/lib (offset 12)
--
  cmd LC_RPATH
  cmdsize 48
 path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12)
--
  cmd LC_RPATH
  cmdsize 32
 path @executable_path (offset 12)
--
  cmd LC_RPATH
  cmdsize 128
 path 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin
 (offset 12)
--
  cmd LC_RPATH
  cmdsize 48
 path /Users/hohndel/src/install-root/lib (offset 12)
--
  cmd LC_RPATH
  cmdsize 48
 path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12)
--
  cmd LC_RPATH
  cmdsize 32
 path @executable_path (offset 12)
--
  cmd LC_RPATH
  cmdsize 128
 path 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin
 (offset 12)
> 
>> So... hear me out here... if Qt can switch to OpenGL... and if this thingy
>> doesn't work unless it's OpenGL... shouldn't Qt simply switch to OpenGL?
>> Or is this too radically useful?
> 
> My guess is that it has to be explicit on your side because Metal has some 
> advantage that OpenGL doesn't. I wouldn't know what, since it's not an area I 
> pay attention to.

:-)

So instead of defaulting to something that works, Qt defaults to something that
may have some vague advantage that you aren't certain about.

Solid reasoning. 藍


I'll keep playing with the rest and send updates once I have more time figuring 
out
the details.

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

Re: [Interest] Qt 6.3.0 Android and SSL feature issue

[Remy Rouvin]

I’ve Clean / Run CMake configuration and it works perfectly.

I should have done that before posting.

Sorry for the inconvenience.

Thank you so much.

 

Rémy

 

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

Re: [Interest] What is the minimum required macOS SDK to build Qt 5.15.9 with support for x86_64 and arm64?

[Thiago Macieira]

On Tuesday, 12 April 2022 01:33:13 PDT Tor Arne Vestbø wrote:
> In the case of ARM support, as Thiago said, the minimum Xcode version we
> support is effectively raised from Xcode 11 to Xcode 12, but I recommend
> Xcode 13.

For me, the problem with Xcode 13 is that it requires a newer version of macOS 
than I have on my Mac Mini. I haven't done the full system upgrade in 2 years 
because I don't want to do it remotely. I'll do it soon when I get to the 
office.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Interest] Creating fat binaries for Qt6 on macOS

[Thiago Macieira]

On Monday, 11 April 2022 23:17:17 PDT Dirk Hohndel wrote:
> > The error message is talking about how the same path was being removed
> > more
> > than once, which means your binary has it twice. I guess this had simply
> > never occurred in the past. Deduplicating the paths is not a bad idea in
> > macdeployqt, but you can also investigate why your build arrived at this
> > point with twice the same rpath and change that.
> 
> I will look into this. I'm thinking that this is a result of this being fat
> binaries with identical rpath in both sides.

It's possible. The tool is parsing the output of otool -l, so if that prints 
the rpaths for both members of the fat binary, it would indeed get confused.

> So... hear me out here... if Qt can switch to OpenGL... and if this thingy
> doesn't work unless it's OpenGL... shouldn't Qt simply switch to OpenGL?
> Or is this too radically useful?

My guess is that it has to be explicit on your side because Metal has some 
advantage that OpenGL doesn't. I wouldn't know what, since it's not an area I 
pay attention to.

> Yes, I'll do that... that requires undoing my "hack" to make things work,
> though. I'm not sure my brain is fresh enough right now to work on that and
> create  useful information. 4+ hours of diving make you tired...

:)
 
> > As you said it works if you build thin binaries, either there's something
> > that remained thin and you're missing it, or most likely there's a
> > failure in that parser trying to find the plugin metadata. If that's the
> > case, please create a bug report and attach the plugin's .dylib, and I'll
> > find out where it went wrong. I might then even add that extra debugging
> > that the other two file formats have.
> 
> I don't think that's it:
> 
> % lipo -info
> ../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/*.dyli
> b Architectures in the fat file:
> ../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/libwor
> kerscriptplugin.dylib are: x86_64 arm64
> 
> We may need that extra debug info :)

I meant the QMachOParser content. I wrote that in 2013 to make it really fast 
to scan files to find out if they are plugins. Before that, Qt opened each 
file and did a full string search, which was slow in debug builds because of 
all the debug info in those files. The code does deal with fat binaries and 
was tested against them but by that time, PowerPC and even 32-bit x86 were 
no longer relevant for macOS. There could be latent bugs.

The ELF parser is much older, from before the Qt public history.

The COFF-PE parser for Windows is new in 6.3.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

[Interest] Qt Creator (6/7) Project Executable Run - Failed to launch /Applications/APP_NAME.app: Permission denied

[Nuno Santos]

Hi,

Since Qt Creator 6 that it seems impossible to launch an app selected as 
executable under project run settings.

Today I have updated to Qt Creator 7 and the problems seems to persist.

When I launch the project, which is a plugin that will be loaded into an 
application, I get:

Failed to launch /Applications/APP_NAME.app: Permission denied

Is anyone else having this issue? What am I missing here?

Thanks!

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

Re: [Interest] Qt 6.3.0 Android and SSL feature issue

[Marius Kittler]

Hi,

I've seen these kinds of error messages a lot also when not cross-compiling. 
They always occurred after upgrading Qt 6.x.x packages (e.g. provided by TW), 
especially when Qt 6 was still in the alpha/beta phase. I could always resolve 
it by simply adapting my CMake config accordingly (or simply starting with a 
clean build directory from scratch).

I don't use official binaries but my own Qt 6.3.0 builds still have contain 
e.g.  "libplugins_tls_qopensslbackend_arm64-v8a.so" and 
"libplugins_tls_qcertonlybackend_arm64-v8a.so" without having to alter any 
build flags. So I don't think TLS support became generally unavailable under 
Android.

Best regards
Marius


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

[Interest] Qt 6.3.0 Android and SSL feature issue

[Remy Rouvin]

Hi everyone,

I try to compile my project with the just released Qt 6.3.0 and I have this
CMake Error:

-

CMake Error at
C:/Qt/6.3.0/android_arm64_v8a/lib/cmake/Qt6/QtFeature.cmake:1249 (message):

  Feature ssl is already defined to be "OFF" and should now be set to "ON"

  when importing features from Qt6::Network.

--

Does this mean that the Qt 6.3.0 compiled package has the SSL feature
disabled ?

 

Best regards

 

Rémy Rouvin

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

Re: [Interest] [Qt iOS - QTBUG-101568] Application takes several seconds to become responsive depending on the number of items in scene

[ekke]

I noticed that since some time iOS apps are really slow in debug mode 
(not only at startup), but run fast in release mode (with compiler on)

(5.15.7 - will use 5.15.9 soon)

BTW: I never have situations where per ex at start-of-app a repeater 
creates many objects, normaly first page the user will see is a 
LoginPage or a HomePage with less objects

follow-up Pages are loaded most times using Loader
ekke
Am 12.04.22 um 13:07 schrieb Nuno Santos:

Hi,

I have a problem were all my apps take several seconds to become 
responsive. The more complex the app is, the more time it takes to get 
responsive to touch. This didn’t used to be this way.


I can easily demonstrate the issue happening with a simple example, 
which does not happen in Windows or Android, only iOS:


https://bugreports.qt.io/browse/QTBUG-101568

Is anyone else having this issue?

I think this issue is particular severe for anyone who has complex 
applications on iOS.


Looking forward to hear the community thoughts about it.

Best,

Nuno

___
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

[Interest] [Qt iOS - QTBUG-101568] Application takes several seconds to become responsive depending on the number of items in scene

[Nuno Santos]

Hi,

I have a problem were all my apps take several seconds to become responsive. 
The more complex the app is, the more time it takes to get responsive to touch. 
This didn’t used to be this way.
I can easily demonstrate the issue happening with a simple example, which does 
not happen in Windows or Android, only iOS:

https://bugreports.qt.io/browse/QTBUG-101568 


Is anyone else having this issue?

I think this issue is particular severe for anyone who has complex applications 
on iOS.

Looking forward to hear the community thoughts about it.

Best,

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

Re: [Interest] qtwebbroser questions

[Hamish Moffatt via Interest]

On 11/4/22 22:52, Alexander Carôt wrote:

Thus, I decided to continue using the minibrowser code which already is Qt6 
ready and worked out fine for me so far. However, here I have the problem that 
it does not store cookies. I did some research and found e.g.

https://stackoverflow.com/questions/19069680/can-you-use-qwebview-cookies-sessions-with-qnetworkaccessmanager

which explains how to set cookies for QWebView but the problem with the example 
code is that QWebView is implemented via QML so the question is how to enable 
cookies this way.



Do you just need to set the persistent cookie policy in QWebEngineProfile?


amish


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

Re: [Interest] qtwebbroser questions

[Hamish Moffatt via Interest]

On 11/4/22 22:52, Alexander Carôt wrote:


Thus, I decided to continue using the minibrowser code which already is Qt6 
ready and worked out fine for me so far. However, here I have the problem that 
it does not store cookies. I did some research and found e.g.

https://stackoverflow.com/questions/19069680/can-you-use-qwebview-cookies-sessions-with-qnetworkaccessmanager

which explains how to set cookies for QWebView but the problem with the example 
code is that QWebView is implemented via QML so the question is how to enable 
cookies this way.



Do you just need to set the persistent cookie policy in QWebEngineProfile?


amish

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

Re: [Interest] What is the minimum required macOS SDK to build Qt 5.15.9 with support for x86_64 and arm64?

[Tor Arne Vestbø]

Hey hey,

You generally want to use the latest Xcode/SDK. 

In the case of ARM support, as Thiago said, the minimum Xcode version we 
support is effectively raised from Xcode 11 to Xcode 12, but I recommend Xcode 
13.

Tor Arne 

> On 11 Apr 2022, at 21:51, Thiago Macieira  wrote:
> 
> On Monday, 11 April 2022 10:42:40 PDT Nuno Santos wrote:
>> My Mac build machine is still running mac OS Mojave 10.14.6 and Xcode 11.3.1
>> due to legacy requirements.
> 
> The SDK for 11.1 (available in XCode 12) has support for ARM:
> 
> /*
> * Architecture validation for current SDK
> */
> #if !defined(__sys_cdefs_arch_unknown__) && defined(__i386__)
> #elif !defined(__sys_cdefs_arch_unknown__) && defined(__x86_64__)
> #elif !defined(__sys_cdefs_arch_unknown__) && defined(__arm__)
> #elif !defined(__sys_cdefs_arch_unknown__) && defined(__arm64__)
> #else
> #error Unsupported architecture
> #endif
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] qtwebbrowser questions

[Alexander Carôt]

see below – I understood that qtbrowser in indeed an example application in 
beta state. Therefore, disabling the virtual keyboard is not supported by 
default. However, it can be achieved by introducing the visibility property in 
the respective QML file (/qml/Main.qml) and set it from the C++ end via e.g. 
object->setProperty("keyboardVisible", false);

Once the port to Qt6 is done I would provide the patches to the main project 
for others to have an up2date code base to build upon.

Best

Alex


--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Montag, 11. April 2022 um 17:32 Uhr
> Von: "Alexander Carôt" 
> An: "Alexander Carôt" 
> Cc: "qt qt" 
> Betreff: Aw: [Interest] qtwebbrowser questions
>
> >> 1.) How can I set an initial URL when opening the browser ?
> 
> After getting familiar with QML I realized that Browserwindow.qml contained a 
> bug:
> 
> navigation.load();
> 
> had to be changed to
> 
> navigation.load(url);
> 
> So this one is resolved – now I check how to disable the virtual keyboard for 
> desktop platforms.
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> 
> > Gesendet: Montag, 11. April 2022 um 08:52 Uhr
> > Von: "Alexander Carôt" 
> > An: "Alexander Carôt" 
> > Cc: "qt qt" 
> > Betreff: Aw: [Interest] qtwebbroser questions
> >
> > Regarding 1.) I realized that the app's initlalURL argument must not 
> > contain "-" (in contradiction to the other app args) so just the plain URL, 
> > however, the site is still not loaded. If anyone can confirm please let me 
> > know. 
> > 
> > 
> > --
> > http://www.carot.de
> > Email : alexan...@carot.de
> > Tel.: +49 (0)177 5719797
> > 
> > 
> > > Gesendet: Sonntag, 10. April 2022 um 21:56 Uhr
> > > Von: "Alexander Carôt" 
> > > An: "qt qt" 
> > > Betreff: [Interest] qtwebbroser questions
> > >
> > > Hi all,
> > > 
> > > while playing with qtqwebbrowser
> > > 
> > > https://code.qt.io/cgit/qt-apps/qtwebbrowser.git
> > > 
> > > the two questions arise:
> > > 
> > > 1.) How can I set an initial URL when opening the browser ?
> > > 2.) How can I disable the virtual keyboard when using desktop platforms ?
> > > 
> > > Thanks as usual,
> > > best
> > > 
> > > Alex
> > > 
> > > 
> > > --
> > > http://www.carot.de
> > > Email : alexan...@carot.de
> > > Tel.: +49 (0)177 5719797
> > > 
> > > ___
> > > 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] Creating fat binaries for Qt6 on macOS

[Dirk Hohndel]

Hi Thiago,

Thanks for the detailed response.

> On Apr 11, 2022, at 13:43, Thiago wrote:
> 
> On Sunday, 10 April 2022 10:22:21 PDT Dirk Hohndel wrote:
>> ERROR: "error:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
>> ain/usr/bin/install_name_tool: \"-delete_rpath
>> /Users/hohndel/src/install-root/lib\" specified more than once\nUsage:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
>> ain/usr/bin/install_name_tool [-change old new] ... [-rpath old new] ...
>> [-add_rpath new] ... [-delete_rpath old] ... [-id name] input\n"
> 
> This one looks like a legitimate bug. The code doing the looping that adds 
> -delete_rpath has been there since 2014 and the man page for it says:
> 
>   -delete_rpath old
>  deletes  the  rpath path name old in the specified Mach-O 
>  binary.  More than one of these options can be specified. [...]
> 
> The error message is talking about how the same path was being removed more 
> than once, which means your binary has it twice. I guess this had simply 
> never 
> occurred in the past. Deduplicating the paths is not a bad idea in 
> macdeployqt, but you can also investigate why your build arrived at this 
> point 
> with twice the same rpath and change that.

I will look into this. I'm thinking that this is a result of this being fat 
binaries with identical
rpath in both sides.

>> QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi()
>> to override the default.
> 
>> That first error is weird... I thought Qt on macOS was using OpenGL..
> 
> No, it now uses Metal. Because Apple likes to deprecate perfectly good APIs 
> and replace with something new. We don't do that on Linux (*cough* PipeWire 
> *cough*)...
> 
> https://doc.qt.io/qt-6/quick-changes-qt6.html#changes-to-qquickwidget
> "QQuickWidget is functional only when the scenegraph is rendering with 
> OpenGL. 
> It will not be functional when using another graphics API, such as Vulkan or 
> Metal. Applications relying on QQuickWidget should force the usage of OpenGL 
> by calling QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL) in 
> their 
> main() function."
> 
> I don't know why the default has changed or why Metal is better. Maybe 
> someone 
> else can chime in.

So... hear me out here... if Qt can switch to OpenGL... and if this thingy 
doesn't work
unless it's OpenGL... shouldn't Qt simply switch to OpenGL?
Or is this too radically useful?

>> And that second one is why I'm mainly writing this message... because
>> QtQml.WorkerScript is there. macdeployqt doesn't copy it (I'll need to
>> figure out how to write a bug report for that one), but I manually copy it
>> in place:
>> 
>> % ls -l ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework
> 
> That's the framework. There must be a plugin somewhere.

I have the plugin in my plugin path.
The error went away after I forced an explicit link against this framework.
Makes no sense to me, TBH

>> Any idea what I may be doing wrong? This appears to work if I only build an
>> arm64 binary. But I get the error above for a fat binary. All the libraries
>> and plugins that I can find are indeed fat, e.g.:
>> 
>> % lipo -info
>> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke
>> rScript Architectures in the fat file:
>> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke
>> rScript are: x86_64 arm64
>> 
>> Any pointers welcome :)
> 
> Probably a failure to load the plugin, for one of two reasons: either 
> QPluginLoader concluded the file in question isn't a valid plugin, or it did 
> but dlopen() subsequently failed.

That's what I thought as well. The debugging output was extremely useless.
And thanks to macOS being infallible, we of course have no decent 'stroke' 
replacement anymore, so that felt hard as well.

> Can you run with QT_DEBUG_PLUGINS=1 set in your environment and see if it 
> logs 
> a reason why? Unlike the new COFF-PE parser and the rewritten ELF parser, I 
> didn't add extra debugging to the Mach-O parser itself in 2013. But it should 
> accurately report at the end why it doesn't think a given .dylib isn't a 
> plugin.

Yes, I'll do that... that requires undoing my "hack" to make things work, 
though.
I'm not sure my brain is fresh enough right now to work on that and create  
useful
information. 4+ hours of diving make you tired...

> As you said it works if you build thin binaries, either there's something 
> that 
> remained thin and you're missing it, or most likely there's a failure in that 
> parser trying to find the plugin metadata. If that's the case, please create 
> a 
> bug report and attach the plugin's .dylib, and I'll find out where it went 
> wrong. I might then even add that extra debugging that the other two file 
> formats have.

I don't think that's it: 

% lipo -info 
../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/*.dylib