The locate command tells me that the file is located in /home/user/Qt/online/6.7.0/gcc_64/lib/cmake/Qt6Core (as expected). I also checked my $PATH and my $LD_LIBRARY_PATH. I did not see anything weird (everything is similar with Qt 6.6.3 that works fine).

@DylanT123 Just run in VPN..it won't crash

@Sachin-Gaikwad

Great! You can now mark this as solved!

Cheers

Hi, your env settings for the plugin paths seem a bit fishy, usually the QT_QPA_PLATFORM_PLUGIN_PATH points to a directory one level below QT_PLUGIN_PATH (assuming you're doing a standard deployment of the plugins where libqxcb.so is residing in a subdirectory called platforms).

You could try:
QT_QPA_PLATFORM_PLUGIN_PATH=/usr/local/my_distro/revision/lib/qt/plugins/platforms
QT_PLUGIN_PATH=/usr/local/my_distro/revision/lib/qt/plugins

Also you could try setting the plugin path explicitly in your main.cpp before calling QApplications's ctor, say like this:

... QCoreApplication::setLibraryPaths("/usr/local/my_distro/revision/lib/qt/plugins"); QApplication a(argc, argv); ...

This will override env settings for the plugin paths.

To debug when the bad 5.15.0 dlls/plugins are pulled in, open a Terminal and type "lsof -c yourappname" to see what dlls are loaded.

@aman_12 Do you mean you're trying to start another application using QProcess?
Or is your application is failing to start?
Where is your binary located (what file system and access rights)?

@quzhuo said in undefined reference to'QCPAxisTickerDateTime':

Sorry to bother you

No problem.
Just remember that after changing pro file you need to rebuild :-)

@JonB Hi!

By "reinstalling everything" I meant VS 2022 and Qt, not the whole Windows OS.

I have tried the solution in the last post of the stackoverflow thread, adding the following lines to my .pro file:

INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.22000.0/cppwinrt/winrt"
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.22000.0/shared"
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.22000.0/ucrt"
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.22000.0/um"
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.22000.0/winrt"

LIBS += -L"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.22000.0/ucrt/x64"
LIBS += -L"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.22000.0/ucrt_enclave/x64"
LIBS += -L"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.22000.0/um/x64"

And the original problems related to the inclusion of stddef.h have gone away. However, now the problems are other.

First: I have a resources file (to include just one image in my app). Well, jom complains about the existence of a .res file that, supposedly, should have been generated somehow.

Second: if I remove the resource file to see what happens, then the problem change and I get this:

LINK : fatal error LNK1158: cannot run 'rc.exe'

Assuming that QtCreator was not able to find rc.exe, I added the following line to my .pro file:

QMAKE_RC = "C:/Program Files (x86)/Windows Kits/10/bin/10.0.22000.0/x64/rc.exe"

which is part of the Windows SDK. However, the problem persists.

So my conclusion is that, by whatever reason, the Windows SDK is not correctly installed and not only the include / library directories are not available, but also other parts required to perform the building.

As I said yesterday, I'm going to uninstall everything, Window SDK, MSVC 2022 and Qt 5.12.2.

I'm not confident at all that this will work. I already did that in the past and it didn't worked, so I had to reinstall Windows completely. However, I must give it a try.

@Pfanne I never used Qt in Visual Studio, so can't help. Maybe somebody else knows.

Attempt # 10 for building on windows [SUCCESS!!]

Started from scratch by re-downloading the source and used the subst command to make a new path to build with.

Created a virtual drive to avoid the PATH length limit: subst a: .\qt-everywhere-src-6.6.2\ created the build folder and ran the configure.bat like the following: PS a:\build> ..\configure.bat

Ran the command cmake --build . --parallel

Ran the install command afterwards

PS a:\build> cmake --build . --parallel

No issues and everything was installed.

I've download the installer again, same hash same problem, so it might be normal.

Should I report this as a bug?
pdv

I changed to Ubuntu 18.04, Qt 5.12.1 compiled and App compiled on Qt creator.
I think because of version series.

Hi,

Did you install the libraries suggested in the error message ?

By the way, which version of Ubuntu are you using ? Depending on that, you might have a more recent version of 5.15 available through the package manager.

Thank you @JonB , I can run my Geant4 program now using VcXsvr instead of Xming.

I first ran Xlaunch under the VcXsvr folder, with interface set as follows:
screenshot.jpg
and then select Disable access control on the last page.

Then I added the following statements to the file ~/.bashrc:

export DISPLAY=`cat /etc/resolv.conf | grep nameserver | awk '{print $2}'`:0.0 export DISPLAY=192.168.144.1:0.0 //[WSL IPv4 Address]:[DISPLAY NUMBER] export WAYLAND_DISPLAY=$DISPLAY export XDG_SESSION_TYPE=x11

Then I can successfully run command startxfce4 to open the Ubuntu virtual desktop, and my Geant4 program can run normally.

I'm still not sure exactly what my problem was, but I'm guessing it's probably because my system is WSL2 (I just found that today and I thought it's WSL1...), and my problem seems to be fixed for now.

Really thank you guys for your help and guidance! Hope everything goes well with you @jsulm @JonB

@piervalli
Hang on, I see a problem!

Go to that cppreference page. Look at the sample code. Go pick the various c++17 compilers it offers. With GCC 13.1 (C++17) it compiles fine. But with GCC 5.2 (C++17) I get the same error as you show.

So which gcc is the MinGW supposed to emulate? You can go to https://godbolt.org/ and play with selecting different compilers, they include MinGW choices. The oldest they have is MinGW gcc 11.3.0, that seems to work (only errors on std::ssize() in that code, which requires C++20, fair enough).