Error 'Importing Specs'

[DaveP]

I am using VisualGDB with Visual Studio 2012 under Windows 10. I am attempting to compile on the PC and run on a Raspberry Pi.

I have set up the toolchain and synchronised sysroot. However, when I exit Makefile Settings, the test runs with ticks all the way down, except ‘Importing Specs’, which is crossed. I had this problem with a ‘real-life’ program but have created a default ‘Hello World’ program (Test4) and this has exactly the same problem.

When I try to build, it complains ‘The system cannot find the path specified’ – without any indication of which path it has a problem with – Build output below.

The program actually compiles and links OK. If I manually copy the executable from Test4\Debug to the /tmp directory on the Pi and change the permissions, it runs fine and up pops ‘Hello World’. This implies that the problems is somehow between VGDB and the Pi.

What is causing this and what can I do about it, please?

Build Output:

1>—— Rebuild All started: Project: Test4, Configuration: Debug Win32 ——

1> The system cannot find the path specified.

1> VisualGDB: using project file C:\Dev\Cpp\Test\Test4\Test4\Test4.vcxproj

1> VisualGDB: using solution file C:\Dev\Cpp\Test\Test4\Test4.sln

1> VisualGDB: using configuration Debug

1> VisualGDB: Attempting inline build…

1> VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean” in directory “C:\Dev\Cpp\Test\Test4\Test4” on local computer

1> The system cannot find the path specified.

1> cmd /C del /S /Q Debug

1> The system cannot find the path specified.

1> C:\Dev\Cpp\Test\Test4\Test4\Debug\Test4.log

1> The process cannot access the file because it is being used by another process.

1> make: *** [clean] Error 1

1> ————————————————————-

1> Command exited with code 2

1> Executable: cmd.exe

1> Arguments: /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean

1> Directory: C:\Dev\Cpp\Test\Test4\Test4

1> Environment: LANG=en_US.UTF-8|PATH=C:\Pi\Toolchain\bin;%PATH%

1>VisualGDB : error : Command-line action failed

1> VisualGDB: Trying to detect if your Makefiles need updating… Using configuration: Debug|Win32

1> VisualGDB: Found a makefile: C:\Dev\Cpp\Test\Test4\Test4\Makefile

1> VisualGDB: Found 1 source file(s):

1> Test4.cpp

1> VisualGDB: Found 0 excluded file(s) for current configuration:

1> VisualGDB: No source changes detected. C:\Dev\Cpp\Test\Test4\Test4\Makefile needs no updating.

1> VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug” in directory “C:\Dev\Cpp\Test\Test4\Test4” on local computer

1> The system cannot find the path specified.

1> C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0 -std=c++11 -DDEBUG -c Test4.cpp -o Debug/Test4.o -MD -MF Debug/Test4.dep

1> C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -o Debug/Test4 -Wl,-gc-sections -Wl,–start-group Debug/Test4.o -Wl,–rpath=’$ORIGIN’ -Wl,–end-group

1> ————————————————————-

1> Command exited with code 1

1> Executable: cmd.exe

1> Arguments: /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug

1> Directory: C:\Dev\Cpp\Test\Test4\Test4

1> Environment: LANG=en_US.UTF-8|PATH=C:\Pi\Toolchain\bin;%PATH%

1>VisualGDB : error : Command-line action failed

1>EXEC : error : Build has failed. See the Output window for more details.

1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(43,5): error MSB3073: The command “”C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe” /rebuild “C:\Dev\Cpp\Test\Test4\Test4\Test4.vcxproj” “/solution:C:\Dev\Cpp\Test\Test4\Test4.sln” “/config:Debug” “/platform:Win32″” exited with code 1.

========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

 

[support]

Hi,

This is strange. What happens if you open command-line prompt in your project directory and run the following commands?

set PATH=C:\Pi\Toolchain\bin;%PATH%
make

Do you get the same error message? Is the .elf file created? What if you run “make all” or “make DEBUG/<ELF FILE NAME>.elf”?

[DaveP]

Hi Bazis,

I set the PATH as suggested and the make completed without error (having deleted the previous binaries). ‘make all’ also did so.

After ‘manually’ setting the path, the error messages from VGDB were the same as before.

However, I searched the disk and could not find a relevant .elf file.

I don’t think the problem is with the ‘make’ but rather with the transfer to the Pi – because the executable is created OK in the PC debug folder (and was also before changing the PATH). If I copy it to the Pi and change the permissions, it runs fine on the Pi.

[support]

Hi,

Sorry, I did not fully understand you. Could you attach some screenshots with setting PATH and building it, showing the PATH setting that breaks and the PATH setting that works?

The transfer to Raspberry Pi happens when you start debugging, so if you get errors during build, they are not related to transfer errors.

[DaveP]

 

Hi,

The build ‘succeeded’ (ie it produced a valid and runnable executable) whether or not I changed the path. I see that the original PATH had c:\SysGCC\Raspberry\bin included (I believe this is the default toolchain location – never used on this PC). I believe the build works OK anyway because the build procedure adds ‘c:\Pi\Toolchain\bin’ to the PATH itself (4th line from bottom in listing above).

Anyway, I added ‘c:\Pi\Toolchain\bin’ permanently to the system path, rebooted and it made no difference. Screenshots of the PATH on the PC and the Pi are below.

So if the executable is being successfully created on the PC, what could give rise to the error messages in the build process? It appeared to me that ‘make’ was being initiated from within a VisualGDB program and – as ‘make’ runs successfully from the command line –  it was other processes within that program that must have been producing the error messages.

You say that the transfer to the Pi happens when debugging starts but surely it must happen before the debug command is executed on the Pi. Is VGDB previously checking that it has a valid path to transfer the executable to (and for some reason not finding it)? My suspicion is that, somewhere within its bowels and only for some purposes, VGDB is still assuming that the toolchain is in its default location (c:\SysGCC…).

One other (possibly irrelevant) fact. The test program (standard, system-generated ‘Hello World’) shows intellisense errors on <iostream>, namespace std;, cout and endl (ie iostream is not being found), even though I have synchronised all includes and libraries in the toolchain (twice). Clearly the compliler is finding the header, as it completes and links OK. Is there some data value or default within VGDB that could be causing this and other problems?

Sorry to ramble a little but, as you can imagine, I am becoming very frustrated with this problem and not getting any work done! Will appreciate your further thoughts.

 

### Path on the PC (line breaks inserted to aid readability)
PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Common Files\Sage SData\;
C:\Program Files (x86)\WinMerge;C:\Program Files\Microsoft\Web Platform Installer\;
C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\;
C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\;
C:\Program Files (x86)\QuickTime\QTSystem\;
C:\Program Files (x86)\MySQL\MySQL Fabric 1.5.4 & MySQL Utilities 1.5.4 1.5\;
C:\Program Files (x86)\MySQL\MySQL Fabric 1.5.4 & MySQL Utilities 1.5.4 1.5\Doctrine extensions for PHP\;
C:\Program Files (x86)\Skype\Phone\;c:\Pi\Toolchain\bin;;C:\SysGCC\Raspberry\bin

### Make successful without errors from PC command line – produces viable executable
c:\Dev\Cpp\Test\Test4\Test4>make
C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0 -std=c++11   -DDEBUG  -c Test4.cpp -o Debug/Test4.o -MD -MF Debug/Test4.dep
C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -o Debug/Test4 -Wl,-gc-sections    -Wl,–start-group Debug/Test4.o   -Wl,–rpath=’$ORIGIN’   -Wl,–end-group
c:\Dev\Cpp\Test\Test4\Test4>

### Path on the Pi
pi@RaspberryPi ~ $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

### Test executable Test4 transferred to the Pi and permissions changed
pi@RaspberryPi ~ $ cd /tmp
pi@RaspberryPi /tmp $ ls -l
total 1244
-rwxrwxrwx 1 pi pi 1239120 Nov  7 17:30 DpDateTest
-rw-r–r– 1 pi pi     313 Nov  8 16:49 ld.so.conf
-rwxrwxrwx 1 pi pi   24772 Nov  8 15:55 Test4

### Test4 running successfully on the Pi
pi@RaspberryPi /tmp $ ./Test4
Hello, World!
pi@RaspberryPi /tmp $

 

[support]

Hi,

Sorry for the confusion. Did I understand you correctly that:

• Building of your project produces a valid executable, but shows the “The system cannot find the path specified” error
• Manually deploying and running the project works
• Debugging your project works
• Testing toolchain fails at the “importing specs” stage and IntelliSense does not get configured properly

If yes, please try adding “-d” to the GNU Make arguments on the Build Settings page of VisualGDB Project Properties. This should force GNU Make to print detailed log on every action it is doing, hopefully revealing what is causing the error message.

If the debugging actually does not start, please enable verbose mode in Tools->Options->VisualGDB->General->Tweaking, start debugging and check for detailed error messages. You can also check the VisualGDB Launcher Output in the Output pane in Visual Studio. Do any of those places contain any extra information about the problem?

 

[pedley]

Sorry to take so long in picking this up but the computer involved is at my holiday home. Everything works fine back at base.

Points all correct above, except #3. The build exits with code 1 and debugging does not start, even though a valid executable has been created.

I have added -d to the Make arguments and this produced a log file of 874K. However, it simply contained bald statements ‘The system cannot find the path specified’, without a hint as to what path it was looking for. It therefore does not help.

I did notice in the log a line ‘Prerequisite c:\pi\toolchain\arm-linux-gnueabihf\include\c++\4.9\iostream' is older than targetDebug/Test5.o’.’. This implies that it has found <iostream>, even though intellisense in the source reports ‘file not found’. I tried explicitly including ‘ c:\pi\toolchain\arm-linux-gnueabihf\include\c++\4.9’ in the ‘Include Directories’ within Projecct Properties|Makefile Settings but this made no difference.

So I am afraid that I am stumped and shall be grateful for any further suggestions.

 

[support]

Hi,

The “The system cannot find the path specified” message is most likely produced not by the Make itself, but by some command that Make launches. Please check the log file for statements like “running command xxx” just before the error message. Then try running the same command manually to see if you can pinpoint the one showing the error.

[pedley]

Firstly, I have found that the header file <iostream> is found if I explicitly add c:\pi\toolchain\arm-linux-gnueabihf\include\c++\4.9 <span style="font-family: Georgia;">to the Intellisense Settings. But why would this not be there implicitly if the toolchain is specified?</span>

However, I can’t (probably through ignorance) deduce anything from the detailed log file. The first line is

“The system cannot find the path specified”. So no associated “running command” Another one appears:

VisualGDB: Run "cmd.exe /c "C:\Pi\Toolchain\bin\make.exe" CONFIG=Debug -d" in directory "C:\Dev\Cpp\Test\Test6\Test6" on local computer
The system cannot find the path specified.
 GNU Make 3.82  ...

Clearly cmd.exe and make.exe have been found, because the make starts OK.

There are in the log file a huge number of lines – 11,000+ of the form:

Updating makefiles....
Considering target file `Debug/Test6.dep'.
Looking for an implicit rule for `Debug/Test6.dep'.
Trying pattern rule with stem `Test6.dep'.
Trying implicit prerequisite `Debug/Test6.dep.o'.

Not sure why this would be normal.

If I were to delete and reinstall VisualGDB, would such toolchain-related issues all be overwritten or would data still be left that could perpetuate the problem. Would I be able to re-use the same licence key (second computer)?

Will appreciate any further thoughts.

• This reply was modified 8 years, 8 months ago by support. Reason: formatting

[pedley]

Sorry about the formatting mess. Clearly I haven’t got the hang of this!

[support]

Hi,

You don’t need to reinstall VisualGDB itself; you can simply delete the Raspberry Pi toolchain and reinstall it. This should help.

Regarding the error, it looks strange. Can you confirm that the “file not found” line is shown BEFORE the “GNU Make 3.82” line? Do you see the same when you try running make.exe in the project directory from Command Prompt manually?

Regarding formatting, we have fixed it, but next time you can just select “Preformatted” instead of “Heading 6” for the pasted text and the forum should display it properly.

[Author]

Posts