Ambiguity in documentation description and reality of problems in practice
-
Latest doc says (https://doc.qt.io/qt-6/qtwebengine-platform-notes.html):
Qt WebEngine can only be built on 64-bit Windows, with a x64-bit toolchain. For building Qt WebEngine for x86 applications, you need to configure and compile Qt with the Visual Studio x64 to x86 cross-compile toolchain. This toolchain can be set up on the command line by running vcvarsall.bat amd64_x86
Let's start from the fact that amd64_x86 is not a modern option - instead of it we must use x64_x86.
And even more! Windows installation of VS already does a set up of 4 special file's shortcuts in Main Menu:
So in fact at docs we MUST to see a direct reference to ONE of these win-shortcuts. And not a text in form like "open terminal, run command, script, bat.... add parameters" - We are no in a linux here guys!
But probably qt developers do not use win platform at all? Who knows?OK, IF mentioned amd64_x86 is in fact equal to x64_x86 - I click the second link from my pic.
Command prompt window is opening and I see that all predefined steps for configuring my building VS2019 platform is performing very well.
So, after that I go into specially created .\Build folder inside the Qt 6.5.0 LTS sources directory, run
..\configure script.-prefix D:\Qt\6.5.0-LTS -debug-and-release -force-debug-info -shared -platform win32-msvc -opensource -confirm-license -qt-doubleconversion -qt-pcre -c++std c++20
Till now All is fine, as it was stated in the output of this script:
Qt is now configured for building. Just run 'cmake --build . --parallel'
I ran this command.
And... after a few hours I've got following (yep, my comp is outdated, i know it, but it still works well for my needs):FAILED: qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp qtwebengine/src/core/Debug/AMD64/QtWebEngineCore D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore cmd.exe /C "cd /D D:\_\6.5.0-source\Build\qtwebengine\src\core && "I:\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe" -C D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64 QtWebEngineCore" ninja: build stopped: subcommand failed.
<sarcasm>A Very useful output of compilation process, Isn't it? </sarcasm>
After another portion of time research tasks I found this:ninja -t msvc -e environment.x86 -- "I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\cl.exe" /c ../../../../../../qtwebengine/src/3rdparty/chromium/base/allocator/partition_allocator/memory_reclaimer.cc /Foobj/base/allocator/partition_allocator/partition_alloc/memory_reclaimer.obj /nologo -DPA_PCSCAN_STACK_SUPPORTED -DUSE_AURA=1 -DTOOLKIT_QT -D_CRT_NONSTDC_NO_WARNINGS -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=NTDDI_WIN10_FE -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DIS_PARTITION_ALLOC_IMPL -Igen -I../../../../../../qtwebengine/src/3rdparty/chromium /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503 /wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389 /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715 /wd4003 /wd4068 /wd5051 /wd4244 /Gy /FS /bigobj /utf-8 /Zc:sizedDealloc- /wd4117 /D__DATE__= /D__TIME__= /D__TIMESTAMP__= /Od /Ob0 /GF /Zi /MDd /wd4577 /std:c++17 /TP /GR- /Fd"obj/base/allocator/partition_allocator/partition_alloc_cc.pdb" memory_reclaimer.cc D:\_\6.5.0-source\qtwebengine\src\3rdparty\chromium\base/allocator/partition_allocator/starscan/state_bitmap.h(239): error C3861: __popcnt64: Identifier not found
HOW is that possible? I see only 2 options:
- DOCS are completely wrong. The first quote from mentioned link contains useless words like: "For building Qt WebEngine for x86 applications, you need to configure and compile Qt with the Visual Studio x64 to x86 cross-compile toolchain." Because practice shows that it's the impossible thing.
- Sources were not tested very carefully. So this theoretically valid option - to compile Qt WebEngine using the cross-compile toolchain - has actually become forbidden....
THUS now I have a main question - how to compile this LTS release? Taking into account that I can't use pure x64 compilation at all.
AND btw HOW to completely disable output of lines like:
Note: including file: D:\_\6.5.0-source\qtwebengine\src\3rdparty\chromium\base/allocator/partition_allocator/starscan/pcscan.h Note: including file: D:\_\6.5.0-source\qtwebengine\src\3rdparty\chromium\base/allocator/partition_allocator/starscan/pcscan_scheduling.h
these "notes" - are madness....
-
In VS2019 sources I found this definition:
__MACHINEX64(unsigned __int64 __popcnt64(unsigned __int64))
file I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\intrin0.inl.h
So for the first sight - it looks like absolutely and pure x64 architecture support ONLY.
So in this case = HOW the documentation on the Qt site could state that
"compile Qt with the Visual Studio x64 to x86 cross-compile toolchain"???? -
In VS2019 sources I found this definition:
__MACHINEX64(unsigned __int64 __popcnt64(unsigned __int64))
file I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\intrin0.inl.h
So for the first sight - it looks like absolutely and pure x64 architecture support ONLY.
So in this case = HOW the documentation on the Qt site could state that
"compile Qt with the Visual Studio x64 to x86 cross-compile toolchain"????@RazerMind
I note that the error message comes fromqtwebengine\src\3rdparty\chromium
. QtWebEngine uses chromium as a third-party component, that's what it wraps. Maybe that no longer works or compiles 32-bit, I don't know.I do know that QtWebEngine is a "big beast", so this might be the case. Qt --- as well as other applications --- is really moving away from 32-bit support. I believe that TQtC only now supplies prebuilt for 64-bit for most/all platforms.
Please remember that this is a user forum, for users like yourself. We are not The Qt Company, who produce Qt. If you feel this is either a documentation bug, a building bug or would like to know whether it is still supposed to work you might raise an issue reporting your finding at https://bugreports.qt.io/ and see what they might have to say.
-
@RazerMind
I note that the error message comes fromqtwebengine\src\3rdparty\chromium
. QtWebEngine uses chromium as a third-party component, that's what it wraps. Maybe that no longer works or compiles 32-bit, I don't know.I do know that QtWebEngine is a "big beast", so this might be the case. Qt --- as well as other applications --- is really moving away from 32-bit support. I believe that TQtC only now supplies prebuilt for 64-bit for most/all platforms.
Please remember that this is a user forum, for users like yourself. We are not The Qt Company, who produce Qt. If you feel this is either a documentation bug, a building bug or would like to know whether it is still supposed to work you might raise an issue reporting your finding at https://bugreports.qt.io/ and see what they might have to say.
@JonB said in Ambiguity in documentation description and reality of problems in practice:
Please remember that this is a user forum, for users like yourself. We are not The Qt Company, who produce Qt. If you feel this is either a documentation bug, a building bug or would like to know whether it is still supposed to work you might raise an issue reporting your finding at https://bugreports.qt.io/ and see what they might have to say.
Huge thx for pointing of that fact! I'm grateful for this...
But even if we here only users - Am I the only one so lucky that I tried to assemble this beast, nothing came of it, and only I have been paying attention to this fact for all this time? After all, judging by the history of the site with documentation from the temporary storage of the Internet, this line about the possibility of cross-compilation has been going on there for many, many years. And no one was interested in this moment? No one really made a FULL instruction - how to assemble all this? Incredible...
-
@JonB said in Ambiguity in documentation description and reality of problems in practice:
Please remember that this is a user forum, for users like yourself. We are not The Qt Company, who produce Qt. If you feel this is either a documentation bug, a building bug or would like to know whether it is still supposed to work you might raise an issue reporting your finding at https://bugreports.qt.io/ and see what they might have to say.
Huge thx for pointing of that fact! I'm grateful for this...
But even if we here only users - Am I the only one so lucky that I tried to assemble this beast, nothing came of it, and only I have been paying attention to this fact for all this time? After all, judging by the history of the site with documentation from the temporary storage of the Internet, this line about the possibility of cross-compilation has been going on there for many, many years. And no one was interested in this moment? No one really made a FULL instruction - how to assemble all this? Incredible...
@RazerMind
I can only say that maybe it used to work fine for 32-bit, but now perhaps chromium itself doesn't support that any longer, as it gets bigger/more hungry. [Update: Searching the web indicates to me that 32-bit chromium should still be supported (still requires a 64-bit machine to build it). Whether there is an issue with Qt-supplied stuff, or with just the cross-compilation, I do not know.]Remember I am not saying that I know it should not work. Only that "less attention" is paid to 32-bit nowadays, and increasingly so. There is a huge amount to do for TQtC for each new release, and e.g. testing cross-compilation to 32-bit under Windows for the (already problematic) QtWebEngine module may not be high on their list. You might still raise a bug there to ask whether it is supposed to work if you really need it.
-
@JonB said in Ambiguity in documentation description and reality of problems in practice:
Please remember that this is a user forum, for users like yourself. We are not The Qt Company, who produce Qt. If you feel this is either a documentation bug, a building bug or would like to know whether it is still supposed to work you might raise an issue reporting your finding at https://bugreports.qt.io/ and see what they might have to say.
Huge thx for pointing of that fact! I'm grateful for this...
But even if we here only users - Am I the only one so lucky that I tried to assemble this beast, nothing came of it, and only I have been paying attention to this fact for all this time? After all, judging by the history of the site with documentation from the temporary storage of the Internet, this line about the possibility of cross-compilation has been going on there for many, many years. And no one was interested in this moment? No one really made a FULL instruction - how to assemble all this? Incredible...
To be fair, using "vcvarsall.bat amd64_x86" is working just fine, and using it is not exactly secret knowledge either (see e.g. https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170) . It also has the benefit of being stable between Visual Studio versions, which is not necessarily true for the start menu shortcuts :)
-
@RazerMind
I can only say that maybe it used to work fine for 32-bit, but now perhaps chromium itself doesn't support that any longer, as it gets bigger/more hungry. [Update: Searching the web indicates to me that 32-bit chromium should still be supported (still requires a 64-bit machine to build it). Whether there is an issue with Qt-supplied stuff, or with just the cross-compilation, I do not know.]Remember I am not saying that I know it should not work. Only that "less attention" is paid to 32-bit nowadays, and increasingly so. There is a huge amount to do for TQtC for each new release, and e.g. testing cross-compilation to 32-bit under Windows for the (already problematic) QtWebEngine module may not be high on their list. You might still raise a bug there to ask whether it is supposed to work if you really need it.
@JonB said in Ambiguity in documentation description and reality of problems in practice:
There is a huge amount to do for TQtC for each new release, and e.g. testing cross-compilation to 32-bit under Windows for the (already problematic) QtWebEngine module may not be high on their list. You might still raise a bug there to ask whether it is supposed to work if you really need it.
Oh yes... I looked in their bug-tracking system for the number of tickets and after I created my own - I don’t even think that the queue for answers will reach me. Such a number of them - I'm just horrified that such a project has so few people at work? That mistakes grow like a snowball and are not corrected ...
-
@JonB said in Ambiguity in documentation description and reality of problems in practice:
There is a huge amount to do for TQtC for each new release, and e.g. testing cross-compilation to 32-bit under Windows for the (already problematic) QtWebEngine module may not be high on their list. You might still raise a bug there to ask whether it is supposed to work if you really need it.
Oh yes... I looked in their bug-tracking system for the number of tickets and after I created my own - I don’t even think that the queue for answers will reach me. Such a number of them - I'm just horrified that such a project has so few people at work? That mistakes grow like a snowball and are not corrected ...
@RazerMind
If you created a bug report there please post a hyperlink here to your issue.They are usually pretty good at looking at all reports and assigning them, even if you might not like the answer they come up with :)
Qt is a big system, so it is expected that there will be lots of bugs reports etc.! I cannot comment on how many people TQtC might or might not employ. Some issues are addressed by open source developers who contribute for free, including several members of this forum.
-
To be fair, using "vcvarsall.bat amd64_x86" is working just fine, and using it is not exactly secret knowledge either (see e.g. https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170) . It also has the benefit of being stable between Visual Studio versions, which is not necessarily true for the start menu shortcuts :)
@kkoehne said in Ambiguity in documentation description and reality of problems in practice:
To be fair, using "vcvarsall.bat amd64_x86" is working just fine
And I didn’t say that it doesn’t work - I clarified that for people who typically work under Windows - there is no habit of using command lines (even if they are developers;) - graphic elements save the brain and hands), and when you/I/they will start checking - and WHAT exactly is indicated in the documentation - and compared with what exactly is indicated in the ready-to-use shortcut - then only questions arise. Yes, this is in fact the same (like your URL is saying) BUT agree that there would be no questions at all - if in Docs we could see a picture! YES - each version of the studio would have its own picture with its 2010/2017/2019/2022 ... versions, but the path was and is and will always be the same ;). And it's easy to find. And what if the developers of the studio suddenly change these constants? Agree that they, in turn, will appeal to the fact that they released the studio installer and it created all the proper shortcuts in the start menu needed to work - so be so kind and please use them ;)
By the way, I seem to have found another bug of compilation.
.\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp line 144
your latest sources have:
const QString timeZone = dt.toString("ttt");
but it must be:
const QString timeZone = dt.toString(QStringLiteral("ttt"));
because ctor of QString class which takes const char* declared as private!
private:
#if defined(QT_NO_CAST_FROM_ASCII)
QString &operator+=(const char *s);
QString &operator+=(const QByteArray &s);
QString(const char *ch);
QString(const QByteArray &a);
QString &operator=(const char *ch);
QString &operator=(const QByteArray &a);
#endif -
@kkoehne said in Ambiguity in documentation description and reality of problems in practice:
To be fair, using "vcvarsall.bat amd64_x86" is working just fine
And I didn’t say that it doesn’t work - I clarified that for people who typically work under Windows - there is no habit of using command lines (even if they are developers;) - graphic elements save the brain and hands), and when you/I/they will start checking - and WHAT exactly is indicated in the documentation - and compared with what exactly is indicated in the ready-to-use shortcut - then only questions arise. Yes, this is in fact the same (like your URL is saying) BUT agree that there would be no questions at all - if in Docs we could see a picture! YES - each version of the studio would have its own picture with its 2010/2017/2019/2022 ... versions, but the path was and is and will always be the same ;). And it's easy to find. And what if the developers of the studio suddenly change these constants? Agree that they, in turn, will appeal to the fact that they released the studio installer and it created all the proper shortcuts in the start menu needed to work - so be so kind and please use them ;)
By the way, I seem to have found another bug of compilation.
.\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp line 144
your latest sources have:
const QString timeZone = dt.toString("ttt");
but it must be:
const QString timeZone = dt.toString(QStringLiteral("ttt"));
because ctor of QString class which takes const char* declared as private!
private:
#if defined(QT_NO_CAST_FROM_ASCII)
QString &operator+=(const char *s);
QString &operator+=(const QByteArray &s);
QString(const char *ch);
QString(const QByteArray &a);
QString &operator=(const char *ch);
QString &operator=(const QByteArray &a);
#endif@RazerMind
dt.toString("ttt");
should work 100% fine, you should not need to writeconst QString timeZone = dt.toString(QStringLiteral("ttt"));
unless you wish to. I think it will match one of https://doc.qt.io/qt-6/qdatetime.html#toString-2 or https://doc.qt.io/qt-6/qdatetime.html#toString at Qt6 (I don't have Qt6); it certainly works in my Qt5.15.3. Show a compilation error message if you claim it generates one, together with the exact version of Qt you are using. -
@RazerMind
If you created a bug report there please post a hyperlink here to your issue.They are usually pretty good at looking at all reports and assigning them, even if you might not like the answer they come up with :)
Qt is a big system, so it is expected that there will be lots of bugs reports etc.! I cannot comment on how many people TQtC might or might not employ. Some issues are addressed by open source developers who contribute for free, including several members of this forum.
@JonB said in Ambiguity in documentation description and reality of problems in practice:
if you created a bug report there please post a hyperlink here to your issue.
yep, of course
https://bugreports.qt.io/browse/QTBUG-113035Also, I can't leave comments quickly. I'm just a beginner))) - says the engine of this forum...
And I would like to give answers as soon as possible))) while there is a "connection" between all of us))) -
@RazerMind
dt.toString("ttt");
should work 100% fine, you should not need to writeconst QString timeZone = dt.toString(QStringLiteral("ttt"));
unless you wish to. I think it will match one of https://doc.qt.io/qt-6/qdatetime.html#toString-2 or https://doc.qt.io/qt-6/qdatetime.html#toString at Qt6 (I don't have Qt6); it certainly works in my Qt5.15.3. Show a compilation error message if you claim it generates one, together with the exact version of Qt you are using.@JonB said in Ambiguity in documentation description and reality of problems in practice:
Show a compilation error message if you claim it generates one.
I can't)) coz I already fix this issue by the provided code.
But I'm surprised you think this code should compile.
I gave you both important pieces of code from the sources, which show that the error will be 100%
("ttt") - This piece of code requires the creation of a temporary QString object. To do this, select one of the existing ctor's is necessarily.
And I gave the code where it is shown - that there is such a QString constructor.
But here's the problem - it is declared in the private part of the class!P.S. why tmp object? because we talk about this declaration:
QString QDateTime::toString(const QString &format, QCalendar cal = QCalendar()) const
but in code developers put not QString object but an object represented by a const string literal "ttt". -
@JonB said in Ambiguity in documentation description and reality of problems in practice:
Show a compilation error message if you claim it generates one.
I can't)) coz I already fix this issue by the provided code.
But I'm surprised you think this code should compile.
I gave you both important pieces of code from the sources, which show that the error will be 100%
("ttt") - This piece of code requires the creation of a temporary QString object. To do this, select one of the existing ctor's is necessarily.
And I gave the code where it is shown - that there is such a QString constructor.
But here's the problem - it is declared in the private part of the class!P.S. why tmp object? because we talk about this declaration:
QString QDateTime::toString(const QString &format, QCalendar cal = QCalendar()) const
but in code developers put not QString object but an object represented by a const string literal "ttt".@RazerMind
Instead of telling me what information you gave me that I should be able to work with. Given that I told youdt.toString("ttt");
works fine for me, at least with my Qt, why don't you spend the 10 seconds to write this line for yourself, compile it, and show the compilation error you say it produces? And I don't know whether you compile with or withoutQT_NO_CAST_FROM_ASCII
if that is relevant. Up to you, I don't need to spend my time looking at this. -
@JonB said in Ambiguity in documentation description and reality of problems in practice:
if you created a bug report there please post a hyperlink here to your issue.
yep, of course
https://bugreports.qt.io/browse/QTBUG-113035Also, I can't leave comments quickly. I'm just a beginner))) - says the engine of this forum...
And I would like to give answers as soon as possible))) while there is a "connection" between all of us)))@RazerMind Alright, commented on the bug report - though you might not like the result, as @JonB already suspected ;) But given that x86 is not supported in Qt 6, we will not spend much time on this.
-
@RazerMind
Instead of telling me what information you gave me that I should be able to work with. Given that I told youdt.toString("ttt");
works fine for me, at least with my Qt, why don't you spend the 10 seconds to write this line for yourself, compile it, and show the compilation error you say it produces? And I don't know whether you compile with or withoutQT_NO_CAST_FROM_ASCII
if that is relevant. Up to you, I don't need to spend my time looking at this.@JonB said in Ambiguity in documentation description and reality of problems in practice:
why don't you spend the 10 seconds to write this line for yourself, compile it, and show the compilation error you say it produces?
First of all it's a problem of Qt 6.5.0 LTS sources compilation - and not my own code ;)
Secondly here we go:FAILED: qtbase/src/plugins/sqldrivers/oci/CMakeFiles/QOCIDriverPlugin.dir/Debug/qsql_oci.cpp.obj
"I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\cl.exe" /nologo /TP -DQOCIDriverPlugin_EXPORTS -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x040800 -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 -DQT_NO_AS_CONST=1 -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_PLUGIN -DQT_SQL_LIB -DQT_WARN_DEPRECATED_UP_TO=0x070000 -DUNICODE -DWIN32 -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -DCMAKE_INTDIR="Debug" -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci\QOCIDriverPlugin_autogen\include_Debug -ID:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\include -ID:_\6.5.0-source\Build\qtbase\include\QtCore -ID:_\6.5.0-source\qtbase\mkspecs\win32-msvc -ID:_\6.5.0-source\Build\qtbase\src\corelib -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0\QtCore -ID:_\6.5.0-source\Build\qtbase\src\sql -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0\QtSql -ID:_\6.5.0-source\Build\qtbase\include\QtSql -external:IC:\oracle\sdk21\include -external:W0 /DWIN32 /D_WINDOWS /Zi /RTC1 -MDd /W3 /EHs-c- /wd4530 /wd4577 -Zc:__cplusplus -permissive- -utf-8 -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:ternary -Zc:externConstexpr -Zc:wchar_t -bigobj -std:c++20 /Foqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\qsql_oci.cpp.obj /Fdqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\ /FS -c D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp
D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp(144): error C2248: QString::QString: cannot access private member declared in class "QString"
D:_\6.5.0-source\Build\qtbase\include\QtCore../../../../qtbase/src/corelib/text/qstring.h(1154): note: see declaration of "QString::QString"
D:_\6.5.0-source\Build\qtbase\include\QtSql../../../../qtbase/src/sql/kernel/qsqlresult.h(17): note: see declaration of "QString"
FAILED: qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp qtwebengine/src/core/Debug/AMD64/QtWebEngineCore D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore
cmd.exe /C "cd /D D:_\6.5.0-source\Build\qtwebengine\src\core && "I:\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe" -C D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64 QtWebEngineCore"
ninja: build stopped: subcommand failed. -
@JonB said in Ambiguity in documentation description and reality of problems in practice:
why don't you spend the 10 seconds to write this line for yourself, compile it, and show the compilation error you say it produces?
First of all it's a problem of Qt 6.5.0 LTS sources compilation - and not my own code ;)
Secondly here we go:FAILED: qtbase/src/plugins/sqldrivers/oci/CMakeFiles/QOCIDriverPlugin.dir/Debug/qsql_oci.cpp.obj
"I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\cl.exe" /nologo /TP -DQOCIDriverPlugin_EXPORTS -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x040800 -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 -DQT_NO_AS_CONST=1 -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_PLUGIN -DQT_SQL_LIB -DQT_WARN_DEPRECATED_UP_TO=0x070000 -DUNICODE -DWIN32 -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -DCMAKE_INTDIR="Debug" -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci\QOCIDriverPlugin_autogen\include_Debug -ID:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\include -ID:_\6.5.0-source\Build\qtbase\include\QtCore -ID:_\6.5.0-source\qtbase\mkspecs\win32-msvc -ID:_\6.5.0-source\Build\qtbase\src\corelib -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0\QtCore -ID:_\6.5.0-source\Build\qtbase\src\sql -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0\QtSql -ID:_\6.5.0-source\Build\qtbase\include\QtSql -external:IC:\oracle\sdk21\include -external:W0 /DWIN32 /D_WINDOWS /Zi /RTC1 -MDd /W3 /EHs-c- /wd4530 /wd4577 -Zc:__cplusplus -permissive- -utf-8 -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:ternary -Zc:externConstexpr -Zc:wchar_t -bigobj -std:c++20 /Foqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\qsql_oci.cpp.obj /Fdqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\ /FS -c D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp
D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp(144): error C2248: QString::QString: cannot access private member declared in class "QString"
D:_\6.5.0-source\Build\qtbase\include\QtCore../../../../qtbase/src/corelib/text/qstring.h(1154): note: see declaration of "QString::QString"
D:_\6.5.0-source\Build\qtbase\include\QtSql../../../../qtbase/src/sql/kernel/qsqlresult.h(17): note: see declaration of "QString"
FAILED: qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp qtwebengine/src/core/Debug/AMD64/QtWebEngineCore D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore
cmd.exe /C "cd /D D:_\6.5.0-source\Build\qtwebengine\src\core && "I:\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe" -C D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64 QtWebEngineCore"
ninja: build stopped: subcommand failed.The OCI build failure is fixed in https://codereview.qt-project.org/c/qt/qtbase/+/466234 , and should be fixed in Qt 6.5.1.
-
@JonB said in Ambiguity in documentation description and reality of problems in practice:
why don't you spend the 10 seconds to write this line for yourself, compile it, and show the compilation error you say it produces?
First of all it's a problem of Qt 6.5.0 LTS sources compilation - and not my own code ;)
Secondly here we go:FAILED: qtbase/src/plugins/sqldrivers/oci/CMakeFiles/QOCIDriverPlugin.dir/Debug/qsql_oci.cpp.obj
"I:\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x86\cl.exe" /nologo /TP -DQOCIDriverPlugin_EXPORTS -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x040800 -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 -DQT_NO_AS_CONST=1 -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_PLUGIN -DQT_SQL_LIB -DQT_WARN_DEPRECATED_UP_TO=0x070000 -DUNICODE -DWIN32 -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -DCMAKE_INTDIR="Debug" -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci\QOCIDriverPlugin_autogen\include_Debug -ID:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\src\plugins\sqldrivers\oci -ID:_\6.5.0-source\Build\qtbase\include -ID:_\6.5.0-source\Build\qtbase\include\QtCore -ID:_\6.5.0-source\qtbase\mkspecs\win32-msvc -ID:_\6.5.0-source\Build\qtbase\src\corelib -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtCore\6.5.0\QtCore -ID:_\6.5.0-source\Build\qtbase\src\sql -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0 -ID:_\6.5.0-source\Build\qtbase\include\QtSql\6.5.0\QtSql -ID:_\6.5.0-source\Build\qtbase\include\QtSql -external:IC:\oracle\sdk21\include -external:W0 /DWIN32 /D_WINDOWS /Zi /RTC1 -MDd /W3 /EHs-c- /wd4530 /wd4577 -Zc:__cplusplus -permissive- -utf-8 -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:ternary -Zc:externConstexpr -Zc:wchar_t -bigobj -std:c++20 /Foqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\qsql_oci.cpp.obj /Fdqtbase\src\plugins\sqldrivers\oci\CMakeFiles\QOCIDriverPlugin.dir\Debug\ /FS -c D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp
D:_\6.5.0-source\qtbase\src\plugins\sqldrivers\oci\qsql_oci.cpp(144): error C2248: QString::QString: cannot access private member declared in class "QString"
D:_\6.5.0-source\Build\qtbase\include\QtCore../../../../qtbase/src/corelib/text/qstring.h(1154): note: see declaration of "QString::QString"
D:_\6.5.0-source\Build\qtbase\include\QtSql../../../../qtbase/src/sql/kernel/qsqlresult.h(17): note: see declaration of "QString"
FAILED: qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp qtwebengine/src/core/Debug/AMD64/QtWebEngineCore D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore.stamp D://6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64/QtWebEngineCore
cmd.exe /C "cd /D D:_\6.5.0-source\Build\qtwebengine\src\core && "I:\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe" -C D:/_/6.5.0-source/Build/qtwebengine/src/core/Debug/AMD64 QtWebEngineCore"
ninja: build stopped: subcommand failed.@RazerMind
It would be really interesting for you to test:QDateTime dt; qDebug() << dt.toString("ttt");
in your own code compiled with your Qt 6.5.
I see @kkoehne has answered that this is a known, fixed bug. I see it is due to
SQL/OCI: Compile with QT_NO_CAST_FROM_ASCII
. -
The OCI build failure is fixed in https://codereview.qt-project.org/c/qt/qtbase/+/466234 , and should be fixed in Qt 6.5.1.
@kkoehne said in Ambiguity in documentation description and reality of problems in practice:
The OCI build failure is fixed in https://codereview.qt-project.org/c/qt/qtbase/+/466234 , and should be fixed in Qt 6.5.1.
Huge thx!
And I also hope that the cross-compilation process will finally be explained - OR it's possible - OR it's NOT possible in today's realities.
-
@kkoehne said in Ambiguity in documentation description and reality of problems in practice:
The OCI build failure is fixed in https://codereview.qt-project.org/c/qt/qtbase/+/466234 , and should be fixed in Qt 6.5.1.
Huge thx!
And I also hope that the cross-compilation process will finally be explained - OR it's possible - OR it's NOT possible in today's realities.
@RazerMind
As you can see, TQtC peeps do look at bug reports pretty promptly :) -
@RazerMind
As you can see, TQtC peeps do look at bug reports pretty promptly :)@JonB
lucky we)))but not enough/////
Coz I still have enough problems. I should have had working support for compiling QPDF* classes. But because it was built into the QWebEngine module, which now only supports x64, so now I've failed... completely...
Main problem of this topic is revealed, but mine problems are still with me... -