I have a problem with debugging my code with GDB. I have compiled the C file and the executable file has been created, yet the path to it seems to not exist when I try to debug it. Do you have any suggestions why is that?
** **
The problem was in unicode characters. I had special characters in my path so GDB could not interpret it
Related
Here I use windows10 cmd. I tried to compile .py to .exe with Nuitka lib and set my own icon to the future app. It worked perfectly without setting icon, but when I try to use:
python -m nuitka --mingw64 --windows-icon-from-ico=my/path/to/the/icon.ico my/path/to/executable/file.py
for compilation, I always catch an error, that says:
"FATAL:
Error, specify only one positional argument unless "--run" is specified to
pass them to the compiled program execution."
As Maxim Paperno noticed, such an error may occur when you have a path to an icon with a space(s) in it. When you have a space in a path and you use such a path in a terminal, then the part after the space is recognized by command string as another positional argument.
P.S. That's a really bad practice to use spaces in folder/file names, it can lead to unexpected errors anytime you work with such paths.
I am trying to get Julia to run on VSCode on windows. I cannot get julia Language server to run. The executable path = "C:\Julia-1.1.1\bin\" which is the correct path. Where am I going wrong?
As stated in the parameter's description, the path should point to the julia executable. You need to add julia.exe to the end.
C:\Julia-1.1.1\bin\julia.exe
If you are editing the JSON file directly, you will need to escape the backslashes.
C:\\Julia-1.1.1\\bin\\julia.exe
The following setting works for me, without the .exe extension.
"julia.executablePath": "C:\\Users\\...\\Julia-1.3.0\\bin\\julia"
I try to compile project using PowerShell command.
Problem is that there is a lot of arguments (75000 characters)
When I try to run compilation I got error:
This command cannot be run due to the error: The filename or extension is too long.
I have also changed value in registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled but it didn’t helped.
I am using Windows 10 Pro.
Do you know where can be problem?
Just in case this grabs anyone else. I received this error but the real problem was my StartInfo.Arguments value was too big. It had nothing to do with the filename I was specifying.
I'm trying to build libpng-1.16.6 as a static lib from VS 2010. I think I've ruled out makefile syntax issues, file system permissions and incorrect LIB/LIBPATH environment variables. The makefile is the unchanged makefile.vcwin32 delivered with lpng1616. I'm certain the issue is environmental, but am out of ideas as to what it is. I'm looking for fresh ideas! TIA for any assistance.
Pertinent facts:
The overall pattern is the same I've used to build geos, gdal and wxWidgets open source projects: A Visual Studio makefile project calls a Windows command file. The Windows command file does any required preprocessing, calls vcvarsall.bar to set up the VS build environment, calls nmake, and performs any required postprocessing. The command file is largely the same, but customized, for each project. The makefile in each case is the one delivered with the source code. A successful retest of my wxWidgets build proves that there has not been an environmental change on my computer causing the libpng failure.
The log output of interest is:
lib -nologo -out:libpng.lib png.obj pngerror.obj pngget.obj pngmem.obj pngpread.obj pngread.obj pngrio.obj pngrtran.obj pngrutil.obj pngset.obj pngtrans.obj pngwio.obj pngwrite.obj pngwtran.obj pngwutil.obj
LINK : fatal error LNK1104: cannot open file 'libpng.lib'
NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\lib.EXE"' : return code '0x450'
Explanation of the log output: Lib.exe is asked to produce libpng.lib from the list of object files. The error is that the output file cannot be open. At this point in the execution of the makefile all object files have been generated, which I have confirmed are present. The library is to be written in the same directory as the object files.
Since the compiler is able to write the object files, there cannot be a write permissions issue in this directory.
Starting a VS command prompt window, navigating to this path and executing the same 'lib' command line the makefile is executing succeeds. Therefore there cannot be a command line syntax error. Running the nmake from the Windows command file from this same VS command prompt also succeeds.
Adding the 'lib' commandl line to the Windows command file immediately after execution of the makefile results in the same error as when run from the makefile.
The natural conclusion is that the problem is the environment in which lib.exe is being executed.
Google results, searching on combinations of 'lib', 'link', 'lnk1104', '0x450', 'nmake', 'makefile', 'makefile.vcwin32', 'works in command line, not in makefile', etc., reveal several patterns. As one would expect, the most common problem is that one of the input files is missing or invalid. (See 3, 4, 5 and 6 above.) I haven't noticed a single case where the file cited in the error message is actually the output file, not an input file. Another common issue that something is wrong with the LIB or LIBPATH environment variables. (I've examined these, comparing the VS command prompt values with the ones from my workflow.)
I've found that apparently lib.exe writes its output to the default output name and renames to the name requested by the '-out' option. If the makefile is altered to build 'tmplibpng.lib' instead of 'libpng.lib' the same error message is generated.
I thought I was being safe. When writing Windows command files I prefix and suffix all 'internal' environment variables with underscore characters to avoid collisions, for example, 'LIB'. Apparently 'LIB' is in use by lib.exe, though it's not in Microsoft's published list. Renaming this environment variable solved my problem.
I am trying to compile a java source file via a Ruby Script. However I am a bit puzzled by the following behavior
compile_results = `javac #{source_file}`
this fails to run with a 'No such file...' error. I popped up irb
irb(main):001:0> `javac -help`
Errno::ENOENT: No such file or directory - javac -help
from (irb):1:in ``'
from (irb):1
irb(main):002:0> `csc`
=> "Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.3053\nfor Microsoft
(R) Windows (R) 2005 Framework version 2.0.50727\nCopyright (C) Microsoft Corpo
ration 2001-2005. All rights reserved.\n\nfatal error CS2008: No inputs specifie
d\n"
However both javac and csc are on the PATH. e.g. if i run javac manually from the shell that I run the ruby script from, I am able to get to the java compiler.
The source file exists.
I tried both ruby 1.8.7 and 1.9.1 (Windows). Does anyone see something that I am missing ?
Update:
I dont think it has to do with command line args. Rather it can't get to javac for some weird reason. I put the line javac %1 in a batch file and call the batch file in the usual way. This worked... but still am not sure of what the whole issue was with javac.
An obvious difference between the two is that you're not running csc with an argument.
Just to get closer to the solution, write a JavaHelp.bat (or .cmd if you prefer), put it on the path and call that from ruby.
Another thing you could try is to call java explicitly as javac.exe . I don't have much hope in that, though, as csc without .exe works too.
Finally, you could try interposing your own shell: Try something like
cmd /c javac -help
(In all this, I'm assuming you're on Windows).
It seems that Ruby on Windows doesn't like the
`command -with-args`
syntax. You might try
%x[javac -help]
or
%x[javac #{source_file}]
or
system 'javac', '-help'
or
system 'javac', "#{source_file}"
Javac may be in your shell's path but as far as Ruby is concerned in this instance it isn't. Csc clearly is in your path and gives you errors as it should but javac doesn't.
If you just run javac does it give you the same ENOENT? If so it's just a path problem. It's entirely possible that your environment in Ruby is different from that in the shell. Can you print out your environment and make sure that the path is actually correct?
Lastly, I don't know if they still use it, I've not used java in ages, but doesn't java have a different path system? I seem to recall you have to set JAVA_HOME or something instead of the path (or in addition to in case the path fails?).
Been a while since I last used windows, apologies if these are all dead-ends.
Do this instead:
`C:/java_location/bin/javac.exe arguments`
And replace the C:/Java_location with the actual location of the JDK. This should work, and you won't need an additional batch file.
Here are a couple of possible reasons:
source_file have spaces somewhere in
its name or path. Quote argument to javac.
source_file is a relative path, but
you cannot get to that relative path
from you current working directory.