In 32 Bit debug mode there is now error at any time.
The MenuBar is the default MenuBar when I start this new project. I don’t touch it or change it any time. I don’t know what is the error on Window1. Analyze project and analyze Window1 bring no problems. After this error I can’t start debug and also I can’t remove the files in the “scratch” folder, because it is in use. So I must quit Xojo, delete the folder and restart Xojo.
I am also experiencing these, deleted any 3rd party Xojo’s plugins still happened, while reporting it the Xojo team mentioned as not-reproduce-able, tried also running Xojo IDE as administrator, the strange thing is it’s only happened when linking the object files into an x64 executable.
The error :
[quote]Linking Executable
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/App.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/FileTypes1.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/CustomData.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/mColorPicker.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/colorPicker.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/MainMenuBar.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/SliderContainer.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: could not open C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/ButtonContainer.o: no such file or directory
C:\Program Files\Xojo\Xojo 2018r4\Xojo Resources\Win32\lld.exe: error: C:\Users
ameless\AppData\Local\Temp\xojo scratch 21416\dataview1.13.3.xojo_binary_project [B10AB748]\Windows_x86_64\/ComboContainer.o: The file was not recognized as a valid object file
[/quote]
Here is the proof the xojo scratch directory do indeed exist
I have moved the project folder into root of C drive but still failed to link the x64 executable.
Although the compilation process seems finished but the Xojo compiler failed to create some of the object files
App.o
FileTypes1.o
CustomData.o
Which looks like a built-in xojo libraries?, it’s quite sad to see a case directly closed without another confirmation on the user, the Xojo’s team always assuming that the fault is on the user not the compiler itself, now i am left with a broken compiler.
[quote=418575:@brian franco]And you cleared the Cache?
C:\Users\YourUserName\AppData\Roaming[/quote]
I haven’t cleared my roaming, hmm, will do it next time.[quote=418588:@]Works here without issue. Try the following:
Delete all folders starting C:\Users
ameless\AppData\Local\Temp\xojo scratch
Try the build again.
Run chkdsk c: from an elevated cmd window
Try the build again.
Turn off any anti virus
Try the build again.
Reinstall Xojo
Try the build again.[/quote]
I did, but doesn’t have any changes
I was shutting down Xojo IDE, cleared out temp folder and re-open Xojo then re-build but the same thing happened
You are correct, instead chkdsk, i was doing sfc /scannow and found some corruption, perhaps because of blackout in my place that was happened.
Now i am in the process of re-installing my windows and toolchains
Only plain vanilla windows defender in my case, haven’t had any issues with these setup before
I was did uninstall R4 and came back with R3 but the same.
For my other project i was needed to turn off windows DEP, perhaps related but let’s see with these new windows install
Strange thing is, it’s still happened :-(, what i have done is.
Tested to run/build on a VM, lower version than currently problematic windows 10 (1809 x64), lld.exe running fine.
Thoroughly checked my environment variable %PATH% just in-case there is the same name lld.exe dependencies in which being picked up by lld.exe.
Turning off windows defender, and to double make sure, adding Xojo installation dir and xojo’s project dir in the exclusion list
Turning off any windows defender registry customization, turning on windows defender’s cutomization on the ‘working’ VM have no minuses turnback (working fine even with the customization)
Using Process Monitor to monitor lld.exe and xojo.exe, somehow i couldn’t find anything wrong other than both of them cannot found some of the compiled object (*.o) files.
Using dependencies walker on the lld.exe in which launched from administrator privilege, the same, nothing wrong with all of the .dll that are being loaded from lld.exe
These are very isolated cases, i hope Xojo team have somekind of debug build for the customer
Take example this error log :
Linking Executable
C:\\Program Files\\Xojo\\Xojo 2018r4\\Xojo Resources\\Win32\\lld.exe: error: could not open C:\\Users\
ameless\\AppData\\Local\\Temp\\xojo scratch 2424\\dataview1.13.3.xojo_binary_project [EFCBA1EC]\\Windows_x86_64\\/App.o: no such file or directory
C:\\Program Files\\Xojo\\Xojo 2018r4\\Xojo Resources\\Win32\\lld.exe: error: could not open C:\\Users\
ameless\\AppData\\Local\\Temp\\xojo scratch 2424\\dataview1.13.3.xojo_binary_project [EFCBA1EC]\\Windows_x86_64\\/FileTypes1.o: no such file or directory
C:\\Program Files\\Xojo\\Xojo 2018r4\\Xojo Resources\\Win32\\lld.exe: error: C:\\Users\
ameless\\AppData\\Local\\Temp\\xojo scratch 2424\\dataview1.13.3.xojo_binary_project [EFCBA1EC]\\Windows_x86_64\\/CustomData.o: The file was not recognized as a valid object file
Furthermore researching it seems that, HoudiniAssistant64.exe , is a somekind of x64 compiler for the xojo code (llvm), while lld.exe is the linker, based on this wild guess, i fired up Process Monitor and guess what, HoudiniAssistant64.exe is never anywhere in Process Monitor log using any windows API to have anything related about,for example above, App.o, which is should be generating/compiling Xojo code by HoudiniAssistant64.exe into an object file (*.o file extension).
This is a clean freshly installed Windows 10 x64 1809.
If any Xojo team reading this, i don’t mind if there is any special debug tools being run on my windows, even better remote trouble shooting.
Found interesting behaviour by Xojo.exe, somehow it trying to create “C:\Users
ameless\AppData\Local\Temp\xojo scratch 2424\dataview1.13.3.xojo_binary_project [EFCBA1EC]\Windows_x86_64\App.o\desktop.ini”, what’s with desktop.ini?, it was pretty old school if my memories serves me right. Instead of creating the App.o object file there is addition of desktop.ini??
At a guess, they have a generic function that checks for a file which they are using to check for the existence of the App.o file. This is probably a generic function that can also check for folders which will also check for the existence of \desktop.ini at the end of that path (in case it has to remove it to empty a folder, another guess).
I think its a little misleading to carry on looking into that. We need to figure out why App.o and a few other files aren’t able to be created on your system where as other files in the same folder are.
Reading into <https://xojo.com/issue/51989> it might just be prudent to zip up C:\Users
ameless\AppData\Local\Temp\xojo scratch 2424\dataview1.13.3.xojo_binary_project [EFCBA1EC] and send it in with a new ticket referencing <https://xojo.com/issue/51989> and see if Xojo can shed any more light on it.
Let them know everything you have tried in the ticket including testing in another vm etc.
I have another theory of it’s being a windows bugs, Windows 10 codename Redstone 5 or 1809 was being delayed for nearly one months since it’s first announcement.
I have used my google ‘kungfu’ in order find a solution to permanently disable creating desktop.ini, the appearing addition of “\desktop.ini” probably just somekind of ‘probe’ by windows internal just in-case user wanted to go in that folder, so windows take pre-caution to ‘probe’ all of the folders when user either enter by windows explorer or by API.
Before sending new feedback i need to more isolating the probable causes, i have imaged my installation so for now wanted to take a stab by installing windows freshly and installing Xojo without any additions, even a driver.
Btw thanks a lot man for making me not feeling alone in this ‘quest’.
Been spending time on downgrading my motherboard bios, the same thing, just in case if Intel Microcode for Spectre mitigation related issues made any differences.
Testing my hardware (RAM,SSD,CPU), still no clue
Downgrading my OS, even plain clean Windows x64 redstone 4 & 5 install make the behavior.
Changing the windows %TEMP% & %TMP% into “C:\temp”, just in-case is Windows path limit thing, but still the same.
But to be noted
Smaller Xojo projects like the one on the example or in the MBS plugin is successfully compiled into x64 Windows binaries, and the same project in which the Windows x64 compilation is failing, the x86 compilation is working fine!. Probably something going on Xojo compiler and linker.
The strange thing is i cannot isolated the issue into specific hardware or software configurations, it’s like my workstation is having a bad ‘karma’. Tested on x64 compilation in my bro notebook and my relative notebook, all is safe sailing :-(.
How long have you been experiencing this, is it a new thing that you’ve just noticed with this project or have you seen it with other projects too?
Are you able to see if its related to project size? I.e. smaller projects work fine and larger projects have issues, do you have other larger projects that you can test against? Like what happens if you compile Examples>Sample Application>EddiesElectronics>Desktop>EEDesktop.xojo_binary_project ?
