I have many C files and I have built it by Visual Studio 2005 by commandline using a makefile.
All the object files are produced correctly and the linking process also works, but the final *.exe is not produced. At the last line, there is the error below. I understand nothing. Can anybody help me?
Here is the error:
process_begin: CreateProcess((null), /link /nologo /subsystem:console /o uartsim.exe xtmpmain.obj ua
rtsim.obj fiber_driver.obj xtmp_options.obj getopt.obj D:\usr\xtensa\XtDevToolsDE\install\tools\RB-2
008.4-win32\XtensaTools\lib\iss\xtmp.lib, ...) failed.
make (e=2): The system cannot find the file specified.
make.exe: *** [uartsim.exe] Error 2
Make can not find the uartsim.exe file. Either it's not on your computer, or it's not in your PATH.
Try to locate the file, check how the file path is passed to Visual Studio (environment variable, absolute path, just the executable name). If it's just the executable name, it means that you must have it in your PATH already to make it work.
Related
in command line examples in windows 10 files seem to just be pulled from thin air? how do i define that?
commands like
gcc --v
or
link /subsystem:console /nodefaultlib /entry:main hello.obj
refer to downloaded files, but if i try to download them and run the identical command i will get an error:
gcc : The term 'gcc' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of
the name, or if a path was included, verify that the path is correct
and try again. At line:1 char:1
why? am i missing something?
Everything in $ENV:Path can be called without specifying a path.
If not, you must specify the path (even the current directory).
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 in the process of creating a visual studio solution to wrap the command-line portions of OCaml. In the standard OCaml make file there is the following target:
version.h : ../VERSION
echo "#define OCAML_VERSION \"`sed -e 1q ../VERSION`\"" > version.h
which I was hoping to simulate via a custom build event. I have modified my vcproj file to include the following lines:
<CustomBuildStep>
<Command>C:\Windows\System32\sed.exe -e "1 s/^/#define OCAML_VERSION " "$(SourceDir)VERSION" > "$(SourceDir)version.h"
</Command>
<Inputs>VERSION</Inputs>
<Outputs>version.h;%(Outputs)</Outputs>
<Message>Building version header file ....</Message>
</CustomBuildStep>
I do have sed installed on my system (from unxutils), and the command does work correctly from a command terminal (after macro-expansion naturally). However, when I execute it from inside Visual Studio I get the following error message:
CustomBuildStep:
Description: Building version header file ....
'C:\Windows\System32\sed.exe' is not recognized as an internal or external command,
operable program or batch file.
I've seen this problem on several forums and the proposed solution is to include the absolute path (which I did) or set the working directory to where the executable lives. Is there anything that I could do to get this to work?
I realize this is going to be an exotic question, but I just can't find the answer.
I'm trying to fix up and enhance an old visual basic-based application.
My problem is: where is the output directory with the compiled binaries?
Thanks.
If some clarification is needed, please ask.
In the .VBP, if there is a line specifying the path like this
Path32="C:\"
Then the resulting EXE will be built at that location. Otherwise, it will be built in the same directory as the .VBP file. The path can be relational as well and may not be a fully qualified path.
I think you want the /outdir switch. This overrides the Path32 setting in the Project file.
VB6[.EXE] [[{/run | /r}] | [/runexit] | [{/make | /m}] projectname]
[/out filename] [/outdir path] [/d const=value{[:constN=valueN]}]
[/mdi | /sdi] [{/cmd argument | /c argument}]
Options:
/run or /r projectname Tells Visual Basic to compile projectname and run it,
using the arguments stored in the Command Line
Arguments field of the Make tab of the Project
Properties dialog box.
/runexit projectname Tells Visual Basic to compile projectname and run it.
Visual Basic will exit when the project returns to
design mode.
/make or /m projectname Tells Visual Basic to compile projectname and make an
executable file from it, using the existing settings
stored in the project file.
/out filename Specifies a file to receive errors when you build using
/m or /runexit. If you do not use /out, command line
bild errors are displayed in a message box.
/outdir path Specifies a directory path to place all output files in
when using /make. This path must already exist.
/d or /D const=value... Tells Visual Basic which values to use for conditional
compilation constants when making an .EXE or ActiveX
component with the /make switch. Separate multiple
constants with colons.
/cmd or /c argument Specifies a command string to be passed to the Command$
function. When used, it must be the last switch on the
command line.
/mdi or /sdi Changes the Visual Basic environment to either Single
Document Interface (SDI) or Multiple Document Interface
(MDI) mode. Visual Basic remains in this mode until
you change it.
/? Displays a list of valid command line switches.
You may use a group name in place of projectname in any of the above switches.
Works fine here.
There is no equivalent 'bin/lib' output directory for VB6. When you compile a VB6 project, the default is to compile to the same folder as the project (vbp file). It is also possible to compile to any other folder available to the user.
I'm using a script to get the subversion head revision number from a subversion repository derived from the script found at http://blog.guymahieu.com/2008/06/09/getting-the-svn-head-revision-number-from-a-windows-batch-file/. The script works fine when called from a normal command line, but when calling the same batch file as pre-build-event with path $(ProjectDir)/../getSVNRev.bat the command svn is unknown.
The path to svn.exe is in the standard system %Path% but it seems that VS uses another path. I echoed the %Path% variable in the batch file and the %Path% seems to be set to the VC++ binary path. I added the path to svn.exe to the VC++ binary path, got that echoed, but still the svn.exe was not found.
I even copied svn.exe and all dlls into system32 but still, the command svn was unknown to the VS command line.
Are there any other locations I should add the path, so that the pre-build event on VS.NET 2003 recognizes svn.exe?
Thanks,
Norbert
I think you want to go to Tools->Options->Projects and Solutions->VC++ Directories, then make sure that "Show directories for" is set to "Exectuable Files" and your platform is set to Win32, then add the directory with the executable to the list, or just add $(Path) to the list so that your system paths end up in there.