Qt6.8.1 building from source - Unable to remove file: error: (32)The process cannot access the file because it is being used by another process

Christian Ehrlicher

I would guess there is a virus scanner around which is a little bit too much interested in those new files. Try to disable them. Also why do you want to build Qt6.8 from source? And you can also build only modules you need and not all by specifying this on the configure command line.

Ben Campbell-Wallis

Hi @Christian-Ehrlicher , thanks for the reply.

I want to build from source so that we are in line with the oss licensing (i assumed this was required after reading the licensing obligations to enable relinking of qt libs to our app by customers?.. ).

Yes I saw that you can pass the submodule to configure which I have just tried, but that also failed (see below failure).
That seems to have create a folder 'qtbase' next to the checked out code:

-- the git checkout
C:\Projects\qt-sources-qtbase
--my build dir
C:\Projects\qt-build-qtbase
-- folder i assume created by my configure with arg cmd
C:\Projects\qtbase

failure -> Invalid command line parameter 'qtbase'.

The command i used is shown below the failure for reference.

Christian Ehrlicher

If you only want to build qtbase then call configure.bat directly from qtbase in your build dir.
You can also call cmake directly - this is at least what I'm doing for qtbase. Building other submodules directly also works later on when you call cmake through the qt-cmake wrapper in <qtbuildir>\bin instead plain cmake.

Ben Campbell-Wallis

Thanks for the hint, I'll give that a try now, feedback shortly...

Ben Campbell-Wallis

@Christian-Ehrlicher

So I did a clean git clone and submodule update just for qtbase.

git clone --branch v6.8.1 https://code.qt.io/qt/qt5.git qt-sources
qt-sources/configure -init-submodules -submodules qtbase
mkdir qt-build
cd qt-build
../qt-sources/configure -init-submodules -submodules qtbase
cmake --build . --parallel

I'm back to the unable to remove file:

This is a company machine running threatlocker but the blocked log is empty during the build (in fact it's empty full stop).

I don't seem to have any issue building the numerous project libs on this PC using cmake.

Any other ideas of the cause looking at the above steps and cmd output?

SGaist

@Ben-Campbell-Wallis hi,

Just for the sake of testing, what happens if you limit the parallelism to 1 ?

Ben Campbell-Wallis

Hi @SGaist , I'll give it a go, feedback soon, thanks.

Ben Campbell-Wallis

Hi @SGaist , so it does appear to have built:

I'll make the same process but with more submodules toe be sure, then I'd say this can be marked as a work-around to seeing such a failure I would expect this to be a machine dependent issue.
Thoughts?
Thanks for the support so far...

SGaist

The next thing I would try is adding more parallelism until it breaks again.

Ben Campbell-Wallis

Hi @SGaist , just an update that I can build all sub-modules with 'parallelism 1'.

I'll up the concurrent processes next but I assume that this is machine dependent...

Are my further testing results required or should this be marked as solved as anyone now reading this thread can attempt the same steps and experiment with how many concurrent processes suit their machine?

SGaist

Your feedback would be very welcome (at least I am interested in the result of your experimentations).

You can mark the thread as solved since you have a workaround but keeping it up to date would be a nice plus.

Ben Campbell-Wallis

Hi @SGaist , I'll give it a go as a background task in the coming days.
Thanks for the support (and @Christian-Ehrlicher also), it's much appreciated.

Ben Campbell-Wallis

Hi @SGaist ,

I tried building with multiple jobs starting at 10, none worked on this machine - so only 'parallelism 1' worked.

Interestingly this is only a problem building MinGW, MSVC was working with no specific parallelism value.

gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 14.2.0

SGaist

Intriguing !
Thanks for the feedback

Ben Campbell-Wallis

Sure is, I can only assume I've hit a combination of hardware/complier/toolchain that exposes a bug somewhere - I may follow this up with GNU on this issue, though reading their guidelines for bugs they may never look at it :-)

I've added my PC spec as this may help others searching for similar issues in the future:

OS Name
-> Microsoft Windows 11 Pro
Version
-> 10.0.26100 Build 26100
System Model
-> Precision 5690
Processor
-> Intel(R) Core(TM) Ultra 7 165H, 3800 Mhz, 16 Core(s), 22 Logical Processor(s)
Installed Physical Memory (RAM)
-> 32.0 GB
Drives size:
-> 1.86 TB (2,045,443,567,616 bytes)

gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 14.2.0