[pedley]

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

[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 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.

 

[pedley]

Thanks, Bazis.

Just to note that this doesn’t work for shared .so libraries when using the cross-compiler. The relative path is somehow encoded with the library file and is used on the execution machine (and hence the library not found).

I would appreciate an example of doing this via the Makefile. In what circumstances would any changes to the Makefile be overwritten by VGDB?

 

[pedley]

Thanks Bazis.

I have eventually worked it out but it is not very pretty. For anyone else looking to do the same thing, the solution was to add a path to the output file name to back it out of the default binary directory, then back into the required one. In my case eg “../../../../Lib/libDpExcepIf.a”. By doing this on the ‘Output file name’, rather than the ‘Binary directory’, it leaves the intermediate object files in the default binary directory and the target directory clean, with just the library files. Not sure how efficient it is but it seems to work.

Each project is in a separate subdirectory (which, for linking purposes, is why it is desirable to keep all output libraries in one place), so makefile names are not a problem.

 

[pedley]

That seems to have been AntiBNI’s problem but is not the answer to mine.

In my case, if I simply copy the libraries to the directory which VGDB sets LD_LIBRARY_PATH to (incorrectly and ignoring project settings), then everything works fine. So it doesn’t appear to be a loader issue – just being told by VGDB to look in the wrong place.

[pedley]

Thanks for your suggestion, AntiBNI. However, I don’t think it applies in my case. I built the Boost libraries with the compiler that came with the Jessie distro and am using that same compiler to build the programs. Admittedly, there could be an inconsistency with the cross-compiler loaded to the PC (identical version) but how could one tell?

I think I know where the LD_LIBRARY_PATH that VGDB uses came from. When I was evaluating VGDB, I used a Wheezy distro and Boost 1.57 was presumably preloaded in that location. I installed version 1.59 at that stage but may originally have reference v1.57 and it somehow stuck in VGDB’s memory. I have subsequently changed to Jessie with a later version of the compiler, loaded and re-compiled Boost v1.59 and copied/synced the toolchain on to the PC.

I have managed to make things work with a hack. I created a new directory on the Pi (/usr/lib/boost_1_57_0/stage/lib – where LD_LIBRARY_PATH thinks the libraries should be) and copied them all from (/usr/boost_1_59_0/lib – the correct location). Thus I have two identical copies, one flagged with an incorrect version number. The second is used by the compiler/linker on the PC (via sync) and the first is used for dynamic linking on execution.

This is very unsatisfactory and is certainly not a “solution”. However, it allows me to make some progress with development before a solution emerges.

Do you have any further suggestions, please, Bazis?

• This reply was modified 9 years, 1 month ago by support.

[pedley]

Hi Bazis,

Thanks for your reply.

No, this prints “/usr/lib/boost_1_57_0/stage/lib”. I have no idea where it gets this from – not even from the old toolchain (I updated from Wheezy to Jessie but the version of Boost on the previous disk was still 1.59). No such directory exists on the PC under ‘sysroot’. If I query the Pi both before and after running the program, it shows LD_LIBRARY_PATH as blank. So presumably VGDB is setting LD_LIBRARY_PATH (to the unhelpful value) immediately before the program runs and restoring the previous value immediately afterwards.

I have tried setting LD_LIBRARY_PATH under ‘Debug Settings’ to both ‘/usr/boost_1_59_0/lib’ and ‘$LD_LIBRARY_PATH:/usr/boost_1_59_0/lib’ but it seems that both are ignored.

If I set the correct LD_LIBRARY_PATH variable directly on the Pi, it is correctly reported:
pi@RaspberryPi /tmp $ export LD_LIBRARY_PATH=/usr/boost_1_59_0/lib
pi@RaspberryPi /tmp $ echo $LD_LIBRARY_PATH
/usr/boost_1_59_0/lib
pi@RaspberryPi /tmp $ ./LogTest
/usr/boost_1_59_0/lib
 So the problem appears to be that VGDB is setting the environment variable to an unknown (probably historical) value and I can see no way of correcting this. Any further ideas, please?

Best Regards,

David

[pedley]

I was having an identical problem using a cross-compiler under Win7 and executing on a Pi. I am trying to link to boost libraries in directory /usr/boost_1_59_0/lib. The minimal test program consists of a ‘local’ shared library DpLog.so and a main program LogTest. There does not appear to be a problem linking to the test library – just the Boost ones.

[I submitted another question without spotting this one. It does not seem to have appeared on the forum. If it does, apologies for the duplicate].

Following the advice above, on the Pi, I found that the LD_LIBRARY_PATH was empty and ldd LogTest and ldd DpLog.so found all the standard libraries but not Boost. So I set LD_LIBRARY_PATH to ‘:/usr/boost_1_59_0/lib’ and ran the program on the Pi without problem (/tmp/LogTest).

However, when I again tried to debug from vgdb, I still had the error:

‘Remote debugging from host 192.168.1.10

/tmp/MyProg: error while loading shared libraries: libboost_log.so.1.59.0: cannot open shared object file: No such file or directory’

Checked that LD_LIBRARY_PATH was still set correctly on the Pi – it was and the program still ran OK from the Pi command line.

 

This seems very strange to me, as the VGDB error seems to be coming from an identical environment to that which works perfectly when run from the Pi.

I attach the various outputs and shall be very grateful for any advice.

 

### Value of LD_LIBRARY_PATH (having been set on the Pi)
pi@RaspberryPi /tmp $ echo $LD_LIBRARY_PATH
:/usr/boost_1_59_0/lib

### ldd on the main program
pi@RaspberryPi /tmp $ ldd ./LogTest
        linux-vdso.so.1 (0x7ef44000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76fa7000)
        DpLog.so => /tmp/./DpLog.so (0x76f96000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ea8000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e2d000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76e00000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76cc3000)
        libboost_log.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_log.so.1.59.0 (0x76c21000)
        libboost_chrono.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_chrono.so.1.59.0 (0x76c0b000)
        libboost_thread.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_thread.so.1.59.0 (0x76be1000)
        libboost_date_time.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_date_time.so.1.59.0 (0x76bc2000)
        libboost_filesystem.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_filesystem.so.1.59.0 (0x76b9e000)
        libboost_system.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_system.so.1.59.0 (0x76b8b000)
        libboost_regex.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_regex.so.1.59.0 (0x76ab9000)
        /lib/ld-linux-armhf.so.3 (0x54b0a000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76aa2000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a7a000)

### ldd on the test shared library
pi@RaspberryPi /tmp $ ldd ./DpLog.so
        linux-vdso.so.1 (0x7ef77000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76fba000)
        libboost_log.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_log.so.1.59.0 (0x76f18000)
        libboost_chrono.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_chrono.so.1.59.0 (0x76f02000)
        libboost_thread.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_thread.so.1.59.0 (0x76ed8000)
        libboost_date_time.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_date_time.so.1.59.0 (0x76eb9000)
        libboost_filesystem.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_filesystem.so.1.59.0 (0x76e95000)
        libboost_system.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_system.so.1.59.0 (0x76e83000)
        libboost_regex.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_regex.so.1.59.0 (0x76db1000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76cc3000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76c48000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76c1b000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76add000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76ac6000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a9e000)
        /lib/ld-linux-armhf.so.3 (0x54ba8000)

### This is the successful run of the test program from the command line
pi@RaspberryPi /tmp $ ./LogTest
Hello, World!
DpLogTest: 1

### Output from the cross-compiler build
1>—— Rebuild All started: Project: DpLog, Configuration: Debug Win32 ——
1>Build started 28/10/2015 17:21:38.
1>Rebuild:
1>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean” in directory “C:\Dev\Cpp\Test\LogTest\DpLog” on local computer
1>  cmd /C del /S /Q Debug
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.dep
1>  C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.log
1>  The process cannot access the file because it is being used by another process.
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.o
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.so
1>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug” in directory “C:\Dev\Cpp\Test\LogTest\DpLog” on local computer
1>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0 -std=c++11  -I=/usr/boost_1_59_0 -DDEBUG  -fPIC -c DpLog.cpp -o Debug/DpLog.o -MD -MF Debug/DpLog.dep
1>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -shared -o Debug/DpLog.so -Wl,-gc-sections   -L=/usr/boost_1_59_0/lib -Wl,–start-group Debug/DpLog.o -lboost_log -lboost_chrono -lboost_thread -lboost_date_time -lboost_filesystem -lboost_system -lboost_regex  -Wl,–rpath=’$ORIGIN’  -Wl,-soname,DpLog.so  -Wl,–end-group
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.57
2>—— Rebuild All started: Project: LogTest, Configuration: Debug Win32 ——
2>Build started 28/10/2015 17:21:39.
2>Rebuild:
2>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean” in directory “C:\Dev\Cpp\Test\LogTest\LogTest” on local computer
2>  cmd /C del /S /Q Debug
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.dep
2>  C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.log
2>  The process cannot access the file because it is being used by another process.
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.o
2>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug” in directory “C:\Dev\Cpp\Test\LogTest\LogTest” on local computer
2>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0  -I../DpLog -DDEBUG  -c LogTest.cpp -o Debug/LogTest.o -MD -MF Debug/LogTest.dep
2>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -o Debug/LogTest -Wl,-gc-sections   -L=/usr/boost_1_59_0/lib -Wl,–start-group Debug/LogTest.o  ../DpLog/Debug/DpLog.so -Wl,–rpath=’$ORIGIN’ -Wl,–rpath=’$ORIGIN/../../DpLog/Debug/’  -Wl,–end-group
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_log.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_chrono.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_thread.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_date_time.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_filesystem.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_system.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_regex.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>
2>Build succeeded.
2>
2>Time Elapsed 00:00:00.69
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
### Output from the debug session started from VisualGDB
Process /tmp/LogTest created; pid = 3524
Listening on port 2000
Remote debugging from host 192.168.1.10
/tmp/LogTest: error while loading shared libraries: libboost_log.so.1.59.0: cannot open shared object file: No such file or directory

Child exited with status 127
GDBserver exiting

 

[pedley]

Thanks, Bazis. That worked fine.

However, I now see that it appears to still load headers for intellisense from the old toolchain location, even though all projects are pointed to the new one. That gives me cause for concern if I delete the old (now redundant) toolchain from the PC. Is there a way to remove reference to the old toolchain from vgdb and make the new one the default?

A separate question, please: how does one change the default compiler flags eg to have ‘-std=c++11’ appear automatically without having to add it each time?

And another: frequently during testing, I want to examine the program output after execution has finished. The ‘Output’ tab always defaults to ‘VisualGDB Custom Shortcuts Output’. Can the default be set to ‘Visual GDB Program Output’ or the setting be remembered from one debug run to the next? Just a minor annoyance.

Regards.

 

[Author]

Posts