(Windows CE 7)
If i give "clean sysgen" (blddemo clean -q), i'm getting following errors:
SYSGEN: BUILDMSG: Found localized resources for Languages ( 0404 0407 0409 040c 0410 0411 0412 0413 0416 0419 041d 0804 0c0a)
Res2Res: ERROR: Failed CreateFileW("C:\DOCUME~1\KESHAV~1.IWA\LOCALS~1\Temp\R2R1000.tmp", RW, RW, 0, Existing, Normal, 0), GetLastError = 5. {log="C:\WINCE700\build.log(18570)"}
Res2Res: ERROR: Failed CreateFileW("C:\DOCUME~1\KESHAV~1.IWA\LOCALS~1\Temp\R2R1000.tmp", RW, RW, 0, Existing, Normal, 0), GetLastError = 5. {log="C:\WINCE700\build.log(18571)"}
NMAKE : fatal error U1077: 'C:\WINCE700\public\common\oak\Bin\i386\res2res.EXE' : return code '0xffffffff' {log="C:\WINCE700\build.log(18572)"}
NMAKE : fatal error U1077: 'C:\WINCE700\sdk\bin\i386\nmake.exe' : return code '0x2' {log="C:\WINCE700\build.log(18574)"}
SYSGEN: ERROR: error(s) in sysgen phase ( ie7 ) {log="C:\WINCE700\build.log(18576)"}
(Error list:
)
Later, if i give "sysgen" (blddemo -q), there will not be any errors and build successful.
What is the reason of this error?
Error code 5 is ACCESS_DENIED. Are you running with administrative privileges on your build machine?
This error was because of Antivirus agent (Symantec Endpoint Protection) running on my system.
It is solved by disabling the SEP program.
Related
I would like to cross-compile some Rust code for a Raspberry Pi, i.e. use the armv7-unknown-linux-gnueabihf linker. In this package, I used the Rodio library for interfacing with the sound system. This package compiles and runs fine on the build OS (macOS) but I cant compile it to the target, because I then get this error.
Compiling backtrace-sys v0.1.33 Compiling alsa-sys v0.1.2 Compiling minimp3-sys v0.3.2 Compiling syn v1.0.16 Compiling lewton v0.9.4 error: failed to run custom build command for `alsa-sys v0.1.2`
Caused by: process didn't exit successfully: `$HOME/Documents/Personal/Code/Projects/rust_playground/handtekening/target/debug/build/alsa-sys-643139a54771ba41/build-script-build` (exit code: 101)
--- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override"', src/libcore/result.rs:1188:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
warning: build failed, waiting for other jobs to finish... error: failed to run custom build command for `backtrace-sys v0.1.33`
Caused by: process didn't exit successfully: `$HOME/Documents/Personal/Code/Projects/rust_playground/handtekening/target/debug/build/backtrace-sys-3dc6e67ada300248/build-script-build` (exit code: 1)
--- stdout cargo:rustc-cfg=rbt TARGET = Some("armv7-unknown-linux-gnueabihf") OPT_LEVEL = Some("0") HOST = Some("x86_64-apple-darwin") CC_armv7-unknown-linux-gnueabihf = None CC_armv7_unknown_linux_gnueabihf = None TARGET_CC = None CC = None CROSS_COMPILE = None CFLAGS_armv7-unknown-linux-gnueabihf = None CFLAGS_armv7_unknown_linux_gnueabihf = None TARGET_CFLAGS = None CFLAGS = None CRATE_CC_NO_DEFAULTS = None CARGO_CFG_TARGET_FEATURE = None running: "arm-linux-gnueabihf-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-march=armv7-a" "-I" "src/libbacktrace" "-I" "/Users/tresink/Documents/Personal/Code/Projects/rust_playground/handtekening/target/armv7-unknown-linux-gnueabihf/debug/build/backtrace-sys-771c80e09bcc7056/out" "-fvisibility=hidden" "-DBACKTRACE_ELF_SIZE=32" "-DBACKTRACE_SUPPORTED=1" "-DBACKTRACE_USES_MALLOC=1" "-DBACKTRACE_SUPPORTS_THREADS=0" "-DBACKTRACE_SUPPORTS_DATA=0" "-DHAVE_DL_ITERATE_PHDR=1" "-D_GNU_SOURCE=1" "-D_LARGE_FILES=1" "-Dbacktrace_full=__rbt_backtrace_full" "-Dbacktrace_dwarf_add=__rbt_backtrace_dwarf_add" "-Dbacktrace_initialize=__rbt_backtrace_initialize" "-Dbacktrace_pcinfo=__rbt_backtrace_pcinfo" "-Dbacktrace_syminfo=__rbt_backtrace_syminfo" "-Dbacktrace_get_view=__rbt_backtrace_get_view" "-Dbacktrace_release_view=__rbt_backtrace_release_view" "-Dbacktrace_alloc=__rbt_backtrace_alloc" "-Dbacktrace_free=__rbt_backtrace_free" "-Dbacktrace_vector_finish=__rbt_backtrace_vector_finish" "-Dbacktrace_vector_grow=__rbt_backtrace_vector_grow" "-Dbacktrace_vector_release=__rbt_backtrace_vector_release" "-Dbacktrace_close=__rbt_backtrace_close" "-Dbacktrace_open=__rbt_backtrace_open" "-Dbacktrace_print=__rbt_backtrace_print" "-Dbacktrace_simple=__rbt_backtrace_simple" "-Dbacktrace_qsort=__rbt_backtrace_qsort" "-Dbacktrace_create_state=__rbt_backtrace_create_state" "-Dbacktrace_uncompress_zdebug=__rbt_backtrace_uncompress_zdebug" "-Dmacho_get_view=__rbt_macho_get_view" "-Dmacho_symbol_type_relevant=__rbt_macho_symbol_type_relevant" "-Dmacho_get_commands=__rbt_macho_get_commands" "-Dmacho_try_dsym=__rbt_macho_try_dsym" "-Dmacho_try_dwarf=__rbt_macho_try_dwarf" "-Dmacho_get_addr_range=__rbt_macho_get_addr_range" "-Dmacho_get_uuid=__rbt_macho_get_uuid" "-Dmacho_add=__rbt_macho_add" "-Dmacho_add_symtab=__rbt_macho_add_symtab" "-Dmacho_file_to_host_u64=__rbt_macho_file_to_host_u64" "-Dmacho_file_to_host_u32=__rbt_macho_file_to_host_u32" "-Dmacho_file_to_host_u16=__rbt_macho_file_to_host_u16" "-o" "$HOME/Documents/Personal/Code/Projects/rust_playground/handtekening/target/armv7-unknown-linux-gnueabihf/debug/build/backtrace-sys-771c80e09bcc7056/out/src/libbacktrace/alloc.o" "-c" "src/libbacktrace/alloc.c"
--- stderr
error occurred: Failed to find tool. Is `arm-linux-gnueabihf-gcc` installed?
warning: build failed, waiting for other jobs to finish... error: failed to run custom build command for `minimp3-sys v0.3.2`
Caused by: process didn't exit successfully: `$HOME/Documents/Personal/Code/Projects/rust_playground/handtekening/target/debug/build/minimp3-sys-592af14148b11e3c/build-script-build` (exit code: 1)
--- stdout TARGET = Some("armv7-unknown-linux-gnueabihf") OPT_LEVEL = Some("0") HOST = Some("x86_64-apple-darwin") CC_armv7-unknown-linux-gnueabihf = None CC_armv7_unknown_linux_gnueabihf = None TARGET_CC = None CC = None CROSS_COMPILE = None CFLAGS_armv7-unknown-linux-gnueabihf = None CFLAGS_armv7_unknown_linux_gnueabihf = None TARGET_CFLAGS = None CFLAGS = None CRATE_CC_NO_DEFAULTS = None DEBUG = Some("true") CARGO_CFG_TARGET_FEATURE = None running: "arm-linux-gnueabihf-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-march=armv7-a" "-I" "minimp3/" "-Wall" "-Wextra" "-DMINIMP3_IMPLEMENTATION" "-o" "$HOME/Documents/Personal/Code/Projects/rust_playground/handtekening/target/armv7-unknown-linux-gnueabihf/debug/build/minimp3-sys-0a9af7541b5f3089/out/minimp3.o" "-c" "minimp3.c"
--- stderr
error occurred: Failed to find tool. Is `arm-linux-gnueabihf-gcc` installed?
warning: build failed, waiting for other jobs to finish... error: linker `arm-linux-gnueabihf` not found | = note: No such file or directory (os error 2)
error: aborting due to previous error
error: could not compile `lewton`. warning: build failed, waiting for other jobs to finish... error: build failed`
I think it is because I didn't compile the rodio package for the target, because all the failing compiling targets are audio related, but I can't find how to include this library in the cross-compilation process.
I have an application that sometimes fails to obtain the path for the AppData folder.
The situation seems only to occur on our Citrix server farm and not for every user and not all the time (I was pretty much unable to reproduce it).
The problem manifests in the following way:
SHGetFolderLocation is called that way:
Value := SHGetFolderLocation (0, CLSID, 0, 0, pidl);
try
case Value of
S_OK:
begin
if not ShGetPathfromIDList(pidl, Path) then
RaiseLastOSError();
Result := trim(string(Path));
break;
end;
else
RaiseLastOSError();
end;
finally
CoTaskMemFree(pidl);
end;
(CLSID is set to CSIDL_APPDATA which is defined as 0x001a)
What we see, according to the stack trace, is that SHGetFolderLocation returns false, triggering a call to RaiseLastOSError which indicates that last error code was 59:
System Error. Code: 59. An unexpected network error occurred
I'm scratching by head trying to find out how I could receive such an error message: even if there was a network issue, I can't see any reason for SHGetFolderLocation to be affected by it.
Any suggestion?
SHGetFolderLocation() and SHGetPathfromIDList() do not report error codes via GetLastError(), so you cannot use RaiseLastOSError() in this situation.
SHGetFolderLocation() returns an HRESULT value. You can pass that value to the RTL's OleCheck() function, which will raise an exception if the HRESULT value represents an error.
Unfortunately, SHGetPathfromIDList() does not report error codes at all, so if you want to raise an exception if it fails, you have to raise your own exception manually.
You should not call CoTaskMemFree() unless SHGetFolderLocation() returns S_OK, as that is the only condition where your pidl is updated to point at allocated memory. Any other return value will set your pidl pointer to nil instead.
Try this:
OleCheck(SHGetFolderLocation(0, CLSID, 0, 0, pidl));
try
if not SHGetPathFromIDList(pidl, Path) then
raise Exception.Create('Cannot get filesystem path from PIDL');
Result := string(Path);
finally
CoTaskMemFree(pidl);
end;
Which can be greatly simplified by just using SHGetFolderPath() instead:
OleCheck(SHGetFolderPath(0, CSIDL, 0, SHGFP_TYPE_CURRENT, Path));
Is MPI_IN_PLACE supported for MPI_Ineighbor_alltoall or is there a problem with the function call? https://www.open-mpi.org/doc/v2.0/man3/MPI_Neighbor_alltoall.3.php says that MPI_IN_PLACE is not supported for send? Doe that implicitly mean it is not supported for receive as well?
If I switch the receive buffer to MPI_IN_PLACE the code breaks
ierr = MPI_Ineighbor_alltoall( &P( 0 ), P.chunkSize, MPI_DOUBLE, &R(0), P.chunkSize, MPI_DOUBLE, nbrComm[0], &request );
ierr = MPI_Ineighbor_alltoall( &P( 0 ), P.chunkSize, MPI_DOUBLE, MPI_IN_PLACE, P.chunkSize, MPI_DOUBLE, nbrComm[0], &request );
with the following error,
*** An error occurred in MPI_Ineighbor_alltoall
*** reported by process [3809738753,4575480487799160832]
*** on communicator MPI_COMM_WORLD
*** MPI_ERR_ARG: invalid argument of some other kind
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
My code opens a virtual NIC device using CreateFile. After that I am calling SetHandleInformation on the handle returned by CreateFile to avoid leaking the handle to child processes. The problem is, SetHandleInformation fails with error code 5 (ERROR_ACCESS_DENIED).
Following is the piece of code where I am opening the device and calling SetHandleInformation:
handle = CreateFile(dev_name, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_SYSTEM | FILE_FLAG_OVERLAPPED,NULL);
if (handle != INVALID_HANDLE_VALUE) {
if (!(SetHandleInformation(handle, HANDLE_FLAG_INHERIT, 0))) {
printf("SetHandleInformation error, code: %u\n", GetLastError());
}
}
I am observing this failure on Windows 10. My application is running with Administrator privileges. I am able to successfully use the handle for read and write even after this failure, which indicates that CreateFile is working fine.
What could be the possible reason of this failure? I could not find much information on SetHandleInformation failure with error code 5.
In porting some working unit tests from Linux to Windows I'm running across a strange problem. It appears that when my tests go to shutdown the server socket, shutdown() returns -1, but WSAGetLastError() returns 0 (and getsockopt( with SO_ERROR ) returns 0, and GetLastError() returns 0 )... So, shutdown() tells me there is an error, but all of the normal calls to see what that problem was are returning "no problem!"... Has anyone ever seen this before?
The code that calls shutdown looks like this:
int ret = ::shutdown( _sok, mode );
if( ret < 0 )
X_THROW(( XSDK::ModuleId, XSDK::F_OS_ERROR, "Unable to shutdown socket."));
When I catch the exception, I call all those GetLastError() functions... Does throwing reset the last errors?
The answer ended up being that nearly any system calls can clear Win32's "LastError()" errors... In my case, throwing an exception meant formatting and logging a message, which caused the error to be clear... And even though I was calling WSAGetLastError() immediately in my catch(...) it was already too late...