I am running a build process and it has failed with this error that I cannot find much about. The error is Error 58, which fails on an object (.o) file. what does this mean?
If you are running on windows: Runtime error 58 usually displays in most Microsoft Windows operating systems. It occurs when Windows cannot insert data into a saved or renamed file that is identical to a file name that already exists in the specified folder.
EDIT: Try doing a clean and getting rid of your intermediate and end files before doing a build. Does it still happen ?
Related
I’m trying to run the following command to generate grpc files:
protoc --proto_path=$PROTO_PATH --plugin=protoc-gen-grpc=$PLUGIN_GRPC --grpc_out=$OUT/grpc $PROTO_FILES
This results in the following error:
/Users/MYUSERNAME/Downloads/protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
I made sure the file from the error message is located at that path and has also the correct permissions.
-rwxrwxrwx# 1 MYUSERNAME staff 6334176 10 Aug 00:03 protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe
I also tried running the command as sudo.
Generating java or kotlin files with --java_out=$OUT/java --kotlin_out=$OUT/kotlin
works perfectly fine, so the problem is --grpc_out=$OUT/grpc
I also downloaded multiple versions of the protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe file but it always results in the same error. I also tried replacing all path variables (e.g. $PROTO_PATH) with their corresponding values, without any effect. I’m using MacBook with M1Pro chip.
The problem is that M1 Macs aren't supported. They have copied over the osx-x86_64 binary and renamed it for osx-aarch_64 as a workaround to make it easier to run with Rosetta. See here for where that change was made and here for the full conversation about supporting M1 Macs.
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.
I am creating setup of large data approximetly 10 GB with NSIS Script and trying to create a single setup (exe). Its giving an Error -
Internal compiler error #12345: error mmapping file (xxxxxxxxxx, xxxxxxxx) is out of range.
Note: you may have one or two (large) stale temporary file(s) left in your temporary directory (Generally this only happens on Windows 9x).
Please tell me how to solve this issue ?
Is there any other way to create a setup for this kinda situation ?
NSIS installers are limited to 2Gb.
If you absolutely need it to be one file and you want to continue to use NSIS you have to append the data to the end of the generated setup. I'm not sure I would recommend that approach but it could work if the appended data is a zip file (or some other format with the header at the end) and you use one of the NSIS zip plugins to extract at run-time...
I have used https://sourceforge.net/projects/nsisbi/ instead of normal NSIS. It solved the problem.
I was using Silent Install Builder 5 and received this same error with a package installer that had LESS that 2 GB total. Once I determined that the NSIS compiler was to blame, I began experimenting with several possible solutions and here's what worked: I downloaded the newer NSISBI compiler from here https://sourceforge.net/projects/nsisbi/ and then did these 3 steps:
Go to C:\Program Files (x86)\Silent Install Builder 5 and renamed the default NSIS folder to a new name.
Copied the NSISBI folder into the C:\Program Files (x86)\Silent Install Builder 5 directory and renamed IT to NSIS.
Tries to compile some large packages above and just below 2GB and the first few tries I would get missing file errors in the Silent Install Builder 5 compiling box. No worries because the missing files are in the old NSIS folder, that's why y9u don't delete it.
Each time find the missing file error displays, find the missing files and copy them into the same folder location in the new NSIS folder. About 3 times you will do this until there are no more errors at all and you can then include the large files without generating the "internal compiler error #12345: error mmapping file xxxx is out of range." error message. NSISBI works!
I have problem. I add new dialog in old project, and I have some error:
X:MEATFACTORYMaterialsMaterials.rc (22): error RC2135 : file not found: 0x19
X:MEATFACTORYMaterialsMaterials.rc (74): error RC2135 : file not found: 128
X:MEATFACTORYMaterialsMaterials.rc (1764): error RC2104 : undefined keyword or key name: IDC_LIST_RESULT
Error executing rc.exe.
What is it means?
codepage in file - win1251
what do me?
I need resolve this problem only for VC6.0
At all, the cause of this error was that in the process of adding resources VS6.0 then why (why ? This is not understood) has created another new file resourse.h in the expansion which was added two do not read Unicode characters. That is, were present in the directory two files resourse.h - and with different content. When I set up the conditions as compile / c 68001 - then picked up by a file with Unicode but not complete - and that caused a second group of errors. And if the file is compiled as ASCII - from the point of view of the file system at the studio had two files with the same name - and not one of them could not read ( of course). That is, if you get this error - check the file resource.h - and places without glitches such as in this case .
It is also (probably) this is due to the fact that VS works for me on virtualke to Linux - but from the point of view of the file system of Linux is nothing extraordinary - just two files with different names.
I am currently trying to debug my Crash-Handler, it is an external executable that gets called when my program finds an unhandled structured exception. I recompiled the crash-handler executable, and when I tested, I got a message: "Program too big to fit in memory".
After digging around for a bit, I found that this was being caused by the CreateProcess call within my unhandled exception filter. I found this post that says that this error message indicates that the executable is corrupted, however if I invoke the CrashHandler.exe from the command line, I get no such error.
Other Information:
I have tried rebuilding my
application and the crash-handler
multiple times in both debug and
release mode.
I have tried giving the running thread 2 orders of magnitude more stack space.
I tested the same CrashHandler.exe in another application that was already using it, and there were no problems.
I tried using a previous version of the exe that worked before, but with the same result.
Restarting the system.
My Call to CreateProcess:
//Fire off the Handler
//HandlerArgs = "CrashHandler.exe arg1 arg2 arg3 etc..."
if(CreateProcess(NULL, HandlerArgs, NULL, NULL, TRUE, CREATE_PRESERVE_CODE_AUTHZ_LEVEL | CREATE_SUSPENDED,
NULL, NULL, &StartupInfo, &NewProcessHandle))
Turns out that one of my post-build hooks was copying over the exe from The source control repository, and the file I had in the source control repository was actually the pdb. While testing I was copying directly to my running folder, and then the hook would copy the "corrupted" exe over again.