createManifestRes was generating a MemoryBuffer from a TemporaryFile, keeping the data but removing the file, before passing the file path to CVTRES.exe, leading to the following error:
CVTRES : fatal error CVT1101: cannot open 'C:\Users\user\AppData\Local\Temp\lld-output-resource-bfee19.res' for reading
With this, we instead create a new TemporaryFile before passing it to cvtres.
Details
- Reviewers
ruiu
Diff Detail
Event Timeline
COFF/DriverUtils.cpp | ||
---|---|---|
437 | Does this work? return MemoryBuffer::getMemBufferCopy(ResFile.getMemoryBuffer().getBuffer()); This creates a copy of memory buffer that do not refer the original memory buffer, so you don't need to define the subclass of MemoryBuffer. |
COFF/DriverUtils.cpp | ||
---|---|---|
437 | I don't think so. The point of the subclass is to keep the TemporaryFile alive. In fact in this particular case we don't really care about the MemoryBuffer, we just stick with it because LinkerDriver::link keep a list of MemoryBuffer to reference resources, then call ConvertResToCOFF on this resource list, but only forward the underlying file path to CVTRES (by adding MB.getBufferIdentifier() to its parameters). |
COFF/DriverUtils.cpp | ||
---|---|---|
437 | I see. Thank you for the explanation. Honestly, I prefer simple code than the runtime efficiency here. How about writing MemoryBuffers to temporary files in convertResToCOFF before passing them to cvtres? |
COFF/DriverUtils.cpp | ||
---|---|---|
437 | It would also work, and be way simpler, yeah. I can make a patch tomorrow if you think it's a better way to do it. |
COFF/DriverUtils.cpp | ||
---|---|---|
437 | It would be slower for sure, but it is probably negligible. We can optimize later if it turns out to be too slow. |
Not much simpler in fact, because we need to handle a vector of files, but more local, so probably easier to understand.
LGTM. Thank you for fixing this!
COFF/DriverUtils.cpp | ||
---|---|---|
613 | Please add a comment why we are doing this; we cannot pass paths of the files because the file may be a temporary file and in that case the path have already been removed. |
Does this work?
This creates a copy of memory buffer that do not refer the original memory buffer, so you don't need to define the subclass of MemoryBuffer.