I'm experiencing a weird problem, I have a header file that is included in source files (c++),now whenever I run 'make' on any source file I get the error:
pin.H: No such file or directory
pin.H is found in a different directory (but in some parent directory of the source files), anyway this shouldn't make a problem in my case, the files (sources, headers, makefile, libraries and even exe. files) are given to us by course staff and it's meant to work this way.
I was able to compile successfully before, but somehow after several attempts to run a test on some source file, I had probably made something wrong, I used 'chmod' on some files (and directories maybe), because while trying to run a test I was getting : "Permission denied", However I doubt that I've made chmod for something that it now can't reach that header file anymore (while compiling).
And if that is the case, can I somehow restore "the initial mode" of the system?
Related
I am using the command: dotnet "myfile.dll"
Initially it was giving me this error: The user's home directory could not be determined. Set the 'DOTNET_CLI_HOME' environment variable to specify the directory to use.
Now after messing around with it, I have moved my files to c:/mydir, and it is giving this error: Failed to initialize CoreCLR, HRESULT: 0x80070057. I found this, but isn't c:/mydir a drive root?
Couple of things I noted:
I am able to run the .dll fine in a different directory.
Both directories contain same files.
The reason I want to run it in c:/mydir is because I am using AWS CodeDeploy, and that is where it copies the files (as far as I know; and the other directories are just the old versions where the files get copied from).
These issues are not linked (the first one I get from running a automated shell script after installation, and the second I get from manually trying to launch the .dll).
If someone could help me solve either one of these issues it would be greatly appreciated.
Try adding Environment=DOTNET_CLI_HOME=/temp to your Service declaration in your .service file. Example syntax:
[Service]
...
Environment=VARNAME=VARCONTENTS
So the actual like would look like this
Environment=DOTNET_CLI_HOME=/temp
I am trying to run the make command, but it says
/bin/sh: line 0: cd: /h1/cs/Desktop/cmake/ME/build: No such file or directory
make: *** [cmake_check_build_system] Error 1
This is possibly caused because I used to keep my files in that directory, but I deleted that directory and I moved the source files, CMakeLists.txt, etc, basically everything, from the old to new directory. The new directory is ws/cs/cmake/ME. Yes, I tried to run make in that new directory, and the error above is what I got. Because the new directory has a massive number of sub-directories, I'm not sure which file I need to change so that it knows about the new directory Where in my new directory do I need to change the path, so I can then run make again?
If you delete and start compiling from a new directory you will get an easy fix.. For other options try searching with combination of file and grep.
Believe this is a CLion question.
I'm late to the party but, if someone's looking then -
delete the cmake-build-debug folder entirely from within the project.
select the folder saying your <PROJECT_NAME>, under which the cmake-build-debug folder was present originally, then right click and Reload CMake Project
While running a script to create an NSIS installer, I'm getting an error I can't figure out. The script copies the files needed to create the installer, and then calls makensis to build the setup.exe.
During the compilation with makensis, I get an error while trying to include a directory structure that was copied before makensis was called.
The error is: File: failed opening file "..\..\..\My\Long\Path\Name\To\File.ext"
It fails reliably on a specific file that is 5 directories deep from the File /r command used to include the directory structure. The total path length is 180 characters, so it is not insanely long.
This error persists even after reboots or deleting and recreating the entire directory structure. To make it even worse, it works fine on another machine.
I've used Process Monitor to watch the usage of the files in the directory, and there isn't anything that is opening the file after the copy completes.
Any idea how to solve this problem?
The complete path (Current directory + relative path) has to be < 260 characters.
Are you sure your Process Monitor filters are correct, there should be some type of action taken that then fails? The "File: failed opening file" message is printed if CreateFile fails...
I was getting the same error and the complete path was < 260 characters.
Problem
File: failed opening file "\FOLDERSHARE\XYZSRelease\XYZV1.2.2\AutoCompleteMenu.dll"
Error in script "C:\TFS\XYZProject\Releases\NullsoftInstaller\XYZWin7Installer.nsi" on line 77 -- aborting creation process
Cause
For some reason when the files are on a Folder Share it doesn't work (I am positive this is a change to the corporate network environment) as it previously was working.
Solution
Put all the files in C:\Temp or another local directory.
InnoSetup appears to be corrupting my executable when compiling the setup project.
Executing the source file works fine, but executing the file after installation produces Win32 error 1006 "The volume for a file has been externally altered".
I've tried disabling compression and setting various flags, to no avail.
Has anyone experienced this?
UPDATE
Okay there's been some twists to the situation:
At the moment, I can even manually copy a working file to the location it is installed to and get "The volume for a file...". To be clear: I uninstall the application, create the same folder and paste the files there and run.
UPDATE 2
Some more details for those that want it:
The InnoSetup script is compiled by FinalBuilder using output from msbuild, also executed by FinalBuilder, running on my machine with XP SP3. The executable is a C# .Net assembly compiled in configuration Release|AnyCPU. The file works when executed in the folder the Install Script takes it from. It produces the same behaviour on an XP Virtual Machine. The MD5 hashes of the source file and the installed file are the same.
Ok, I just received this same error. I have a config which my executable uses. I looked in my folder a million times - but finally notice the config file was zero length. I corrected the config and the error stopped occurring.
Check the simplest things first... good lucK!
ERROR_FILE_INVALID
1006 (0x3EE): The volume for a file has been externally altered so that the opened file is no longer valid.
I suspect you're having this issue after moving the files to a network share. It seems to me that what's happening is you have an open file-handle - possibly to a temporary file you are creating - and then some other process (perhaps running on a different host) is coming along and renaming or deleting that file or its' parent directory tree.
So my advice is:
Try installing to a local directory
Run after an anti-virus scan, in
safe-mode or on a different machine
to see if there isn't some
background nasty changing
volume/directory properties while
your program is running.
Make sure the program itself isn't doing anything weird with the volume or directory tree you're working with.
Never seen that before. I've got a few questions and suggestions:
- Are you signing the EXE during the compile of the setup? If so, try leaving that part out.
- WHat OS are you installing on or does it happen on all machines you've tried?
- Run the install with the /LOG="c:\install.log" option and post the log. It might show something happening during install.
- Run a byte compare or MD5 check on the source EXE and the installed EXE. Are they the same? Do they have the same version resource?
So I have scons working with an alternate build location (build/ for my output files, src/ for my input files) and it works great. Except for one thing.
I'm using an IDE (TI Code Composer 4) to debug my program. I point the IDE at the output executable to run it, and what it uses for the source files for debugging is the build/ directory. I don't really care, except when I go to edit the file in the IDE, for example main.cpp, the file is really build/main.cpp which gets clobbered as soon as I run scons again. I have to remember to edit src/main.cpp instead. I am aware of this issue and yet I make the same mistake often.
Is there a way to have scons make the source files it copies into the build path read-only? (I'd ask how to get TI CCS4 to use the right source files when it is debugging an executable, but I doubt I'd get any answers.)
This page has information about wrapping InstallTargets with a chmod call.
FYI, the scons user list is quite active with many knowledgeable people and you can get answers pretty quickly.
You could always tell scons not to duplicate source files in the build directory:
SConscript('src/SConscript', variant_dir='build', duplicate=0)