After "Generate programming file" for a easy FPGA LED project using the Xilinx 14.7 ISE (nt64) I got the following error:
Started : "Map".
Running map...
Command Line: map -intstyle ise -p xc6slx45-csg484-2 -w -logic_opt off -ol high -t 1 -xt 0 -register_duplication off -r 4 -global_opt off -mt off -ir off -pr off -lc off -power off -o LED_map.ncd LED.ngd LED.pcf
'C:\PROGRA~2\MICROS~2.0\VC\include\map' is not recognized as an internal or external command, operable program or batch file.
Process "Map" failed
I tried to solve the problem changing my path to:
PATH=C:\Xilinx\14.7\ISE_DS\ISE\bin\nt64;C:\Xilinx\14.7\ISE_DS\ISE\lib\nt64;C:\Xilinx\14.7\ISE_DS\ISE\..\..\..\DocNav;C:\Xilinx\14.7\ISE_DS\PlanAhead\b
in;C:\Xilinx\14.7\ISE_DS\EDK\bin\nt64;C:\Xilinx\14.7\ISE_DS\EDK\lib\nt64;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu
\powerpc-eabi\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnuwin\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\arm\nt\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt64_be\bin;C:\Xilinx\14.7\ISE_DS\EDK\gnu\microblaze\linux_toolchain\nt64_le\bin;C:\Xilinx\14.7\ISE_DS\common\bin\nt64;C:\Xilinx\14.7\ISE_DS\common\lib\nt64;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\MinGW\bin;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program Files (x86)\OpenNI\Bin;C:\Program Files (x86)\PCL\bin;
However it doesn't work.
Looking in the folder of VisualStudio 2010 ('C:\PROGRA~2\MICROS~2.0\VC\include\map'), I found the map file, which obviously does not correspond to the map file looked for Xilinx ISE.
My fast and ugly solution was to change the name of the folder C:\PROGRA~2\MICROS~2.0\VC\include to C:\PROGRA~2\MICROS~2.0\VC\ _include
And finally Xilinx finds the corresponding map file and it works. However if I want to use VS2010 for other projects I need to rename the include folder again and "Generate programming file" in ISE doesn't work any more.
I was wondering if somebody can help me with a better solution to avoid that Xilinx looks for the file map in the include folder of MVC2010. It should find the map file directly in C:\Xilinx\14.7\ISE_DS\ISE\bin\nt64.
Thanks in advance.
I found this workaround on LabVIEW's website:
http://www.ni.com/product-documentation/13219/en/#308548_by_Category
The Xilinx map program can crash if a file named "map" can be found anywhere on your system path.
When LabVIEW FPGA is running a compile, if a file named "map" can be found anywhere on your system path, then compilation will fail partway through. When compilation fails for this reason, the Xilinx log will contain an error with a message similar to the following: C:\PROGRA~2\MICROS~1.0\VC\include\map' is not recognized as an internal or external command, operable program or batch file. Process "Map" failed
Workaround: There are two workarounds.
Make a copy of the map.exe executables in your Xilinx bin directories.
For example, for Xilinx 12.4 32-bit and 64-bit, make a copy of c:\NIFPGA\programs\xilinx12_4\ISE\bin\nt\map.exe in c:\NIFPGA\programs\xilinx12_4\ISE\bin\nt\map and a copy of c:\NIFPGA\programs\xilinx12_4\ISE\bin\nt64\map.exe in c:\NIFPGA\programs\xilinx12_4\ISE\bin\nt64\map.
Remove from your system path any directories that have files whose names match those of Xilinx executables but have no extension (i.e. map, par, trce, coregen). Restart the compile worker if it is running.
Related
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
As a last step to my maven build on Windows, it tries to create a dll file by linking around 1500 object files. Looks something like this:
cl.exe foo.dll (around 1500 .obj files) (couple of other statically linked libraries)
The build fails with just one statement:
The command line is too long.
Have tried to search the solution here, here and here but the solutions are more context specific rather than something more generic. Could any one suggest what I can do?
I think I got the answer to my question.
I can bundle the arguments of the command in an .rsp file and fire it up on my command prompt with the executable after prepending its path by '#'.
So, for this command:
cl.exe foo.dll (around 1500 .obj files) (couple of other statically linked libraries)
I put this
foo.dll (around 1500 .obj files) (couple of other statically linked libraries)
inside a file say makeDLL.txt. Change it to a .rsp file by changing its extension (makeDLL.rsp) and fire up this command:
cl.exe #<full-path of makeDLL.rsp>
This worked for me.
I am trying to compile the Boost library for Windows (as a prerequisite for building the Bitcoin client), using the MinGW compiler toolchain to do so (rather than Visual Studio) and running into errors.
Following various guides online, I have a working bjam application, and the boost_1_55_0 source files. I have tried in the windows shell doing:
path/to/bjam.exe toolset=gcc --build-type=complete stage (the instructions that Bitcoin provides), but get mingw.jam: No such file or directory errors
bootstrap mingw from a standard DOS shell runs successfully, but the .\b2 after emits a bunch of 'cl' is not recognized as an internal or external command, operable program or batch file errors, implying it's not really set up to use gcc/mingw, since it's calling for the Microsoft compiler.
bootstrap.sh --with-toolset=mingw from the MSYS prompt (as suggested here, which creates a log file that doesn't have as many errors, but running ./b2 after leads to a mingw.jam no such file error, and mingw.init unknown error.
Downloading the compiled binaries from http://sourceforge.net/projects/boost/files/boost-binaries/1.55.0/ (boost_1_55_0-msvc-12.0-64.exe). After extracting and referring to the lib and header files, compiling the final executable throws a whole bunch of undefined reference to 'boost::system::generic_category()' for various boost features, implying to me the library files aren't actually containing the proper definitions? Is that because they're Visual Studio libraries?
Downloading the archives from http://www.boost.org/users/history/version_1_55_0.html (boost_1_55_0.7z), which the documentation implies comes with a pre-compiled lib dir, but does not in fact.
So, I'm banging my head on several walls at once. Can anyone help me get past any of these roadblocks?
I used the following steps to successfully build boost version 1.54 in a MinGW/MSYS environment:
Build bjam.exe and b2.exe:
boost_1_54_0\tools\build\v2\engine>build.bat mingw
Copy build tools to the root-directory:
cp boost_1_54_0\tools\build\v2\engine\bin.ntx86\*.exe boost_1_54_0
Run bjam.exe:
bjam --toolset=gcc --build -type=complete install > boost_build.log
I used this process with slight variations for various boost versions, so its a good guess it will work for 1.55 too
I downloaded Mono and installed it on Win 7 64bit
I went to this site to follow the instructions http://www.mono-project.com/Mono_Basics
I opened up the mono command prompt and compiled and ran the console hello world
then I tried to compile the windowed hello world example with
gmcs hello.cs -pkg:gtk-sharp-2.0
and I get this
C:\Code\NoControl\Mono>gmcs hello.cs -pkg:gtk-sharp-2.0
error CS0006: Metadata file `C:/PROGRA\~2/MONO-2\~1.8/lib/mono/gtk-sharp-2.0/pango-sharp.dll' could not be found
error CS0006: Metadata file `C:/PROGRA\~2/MONO-2\~1.8/lib/mono/gtk-sharp-2.0/atk-sharp.dll' could not be found
error CS0006: Metadata file `C:/PROGRA\~2/MONO-2\~1.8/lib/mono/gtk-sharp-2.0/gdk-sharp.dll' could not be found
error CS0006: Metadata file `C:/PROGRA\~2/MONO-2\~1.8/lib/mono/gtk-sharp-2.0/gtk-sharp.dll' could not be found
error CS0006: Metadata file `C:/PROGRA\~2/MONO-2\~1.8/lib/mono/gtk-sharp-2.0/glib-sharp.dll' could not be found
Compilation failed: 5 error(s), 0 warnings
How do I fix this?
This is the similar to the question here cannot compile hello.cs for gtk# using mono command prompt which was not answered.
Does -pkg work on Windows?
Do I have to download something extra?
The abbreviated path mentions ~1.8/ should it say something like ~10.8
being that my version of mono is 2.10.8?
These were helpful answers for pointing out the root cause of the problem. However, the simplest solution by far is to install Mono into a folder that doesn't have spaces in the name. While installing, just select something like "C:\SDK\Mono". Problem solved, and no funky work-arounds necessary.
A work-around I have found to work on Windows 7 where Mono has been installed as a subdirectory of 'Program Files' is to create a folder in the root of C: to hold directory links (for instance called MonoLinks.. NB no space in the name) and then, from a command prompt go into this directory and create a Directory Junction, giving it a name that does not include a space.
C:\MonoLinks>mklink /J Mono "C:\Program Files\Mono-2.10.8"
This has the effect of creating a traversable directory (link) named Mono that will not only show the contents of the Mono installation but will be accessible to programs without being translated to its original pathname. This could, just as easily, be created in the root of C: but having a generic folder (MonoLinks) there allows for additional links, if needed, to be created within it without cluttering up the root of C:.
The next thing (which had to be done anyway as the PATH environment variable was not updated during the installation) is to update the PATH environment variable so that it points to the bin directory within the installation.
Within Control Panel, User Accounts, select Change My Environment Variables and edit the PATH variable to include C:\MonoLinks\Mono\bin (i.e add semicolon and the path to the end of the PATH property's text).
-pkg seems to be flawed on Windows. On a clean command prompt, if you put Program Files\Mono\bin on your PATH, gmcs will choke on the syntax and will give errors regarding Files\Mono\..., indicating an error related to the spaces in the pathname. If you put PROGRA~1\MONO\bin on your PATH or use the Mono command prompt, it will choke and give errors regarding PROGRA\~1/MONO/..., indicating an error related to tildes (etc.) and escaping them.
Note that although I've given 32-bit examples, there is no reason why this shouldn't apply to 64-bit editions, PROGRA~2 and Program Files (x86).
A workaround I've found is to give individual -r[eference] parameters to gmcs based on the information pkg-config returns, using full paths. Try:
gmcs hello.cs -r:C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/gtk-sharp.dll
-r:C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/gdk-sharp.dll
...
or better yet:
gmcs hello.cs -r:"C:\Program Files (x86)\Mono-2.10.8\lib\mono\..." -r:"..."
(i.e. full paths)
If you're using NAnt, try removing <pkg-references/> and adding:
<include name="C:\Program Files\Mono\lib\mono\gtk-sharp-2.0\gtk-sharp.dll" />
<include name="C:\Program Files\Mono\lib\mono\gtk-sharp-2.0\gdk-sharp.dll" />
...
under <references/>.
Please excuse my use of inconsistent and incomplete path names; this answer is meant to be a guide, not a copy-paste-solution.
I have encounter a problem using gdb to debug vlc.exe in windows environment. I follow the instruction on http://wiki.videolan.org/Win32Compile and successfully compiled and packaged VLC under linux.
The program is running fine and I got the symbol table in the project folder too. However I'm not able to let the gdb load the necessary symbol files to set up break point and stuff.
Under the vlc folder, the object file is listed under like
./win32/*/*/*.o
and the executable is stored in
./win32/vlc-2.1.0-git/vlc.exe
"gdb vlc.exe" in Cygwin shell loads not much useful symbols.
I tried symbol-table command to load a specific symbol file. It loads file and I can see the function in the break prompt. But when I run the program I got the warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x2800: Input/Output error.
Is there a way to feed gdb with the symbol files so that I can debug it like in linux environment?
Here's a little background if anyone's interested in why am I doing this.
I'm studying the VLC codebase about its wrap over DXVA2 interface. The project is pretty big and complex with lots of function pointers trying to mimic a C++ inheritance and encapsulation which makes it hard to understand.
My purpose is to step through the VLC source code on the DXVA2 (Microsoft DirectX Video Acceleration 2) h264 path, which only runs on windows platform. AFAIK vlc don't have a IDE project file that I could use for compile and debugging. I choose cross compilation because VLC website suggests it and I thought if I can get the symbol file, source code and the executable, I can debug it.
Help will be much appreciated. Thanks in advance.
I found out the solution.
gdb needs to know where to load the symbol file, which can be done using the path function or adding the symbol files location at path.
gdb also needs to know where to load the source file, which can be done directory function or specify when the program starts.
This is what I do:
Add this in my .bashrc file:
PATH=$PATH:[vlc proj folder]
export PATH
Then start gdb like:
gdb `find [vlc proj folder] -type d -printf '-d %p '` vlc.exe
:)