Sysprogs forums › Forums › VisualGDB › Linking Symbolic Link Paths to Windows Directory
- This topic has 3 replies, 2 voices, and was last updated 9 years, 3 months ago by support.
-
AuthorPosts
-
August 1, 2015 at 00:51 #6767dmitryponvParticipant
Good Afternoon,
I am very close to getting a large cmake project ported over from eclipse, which has been increasingly unreliable, to VisualGDB, which has proven to be more stable and easier to use.
I have been able to include all of the necessary folders and includes and I copied my entire arm toolchain Xubuntu using “cp -RL”. The -RL option replaces all symbolic links with copies of the file they link to.
Everything works fine and compiles 100% except that I get underfined references in the linker, when some text files files, like libc.so, specify direct paths, like /usr/lib.
For example, libc.so is really a text file that has contents:
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-armhf.so.3 ) )Where the /lib/ and /usr/lib/ paths try to look for files fromt he root directory, and fail.
If I change it to this:
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( libc.so.6 libc_nonshared.a AS_NEEDED ( ld-linux-armhf.so.3 ) )it works, but then I need to edit a lot of the text .so files, and I need to do this every time the toolchain is recompiled, which is very often.
I understand the Path Mapping feature of VisualGDB is supposed to fix this issue,
However, I tried adding the following parameters, and this never made any of the errors disappear:
Additional Source Path Mappings:
/usr/lib D:\sysroots\cortexa9hf-vfp-neon-poky-linux-gnueabi\usr\lib
/lib D:\sysroots\cortexa9hf-vfp-neon-poky-linux-gnueabi\libAbsolute Paths (starting with ‘/’)
D:\sysroots\cortexa9hf-vfp-neon-poky-linux-gnueabi
Relative Paths:
D:\sysroots\cortexa9hf-vfp-neon-poky-linux-gnueabi
Tried combinations of GDB Path Styles:
CygWin [c:\dir\file.cpp]
CygWin [c:/dir/file.cpp]
MinGw [c:\dir\file.cpp]
MinGw [c:/dir/file.cpp]
Is this correct? What May I be setting wrong?
- This topic was modified 9 years, 3 months ago by dmitryponv.
- This topic was modified 9 years, 3 months ago by dmitryponv.
August 1, 2015 at 02:39 #6773supportKeymasterHi,
VisualGDB path mappings only affect the error messages and paths reported by the debugger; they do not change the inner logic of the toolchain.
You can use the ‘=’ prefix to specify paths relative to the sysroot, e.g.:
GROUP ( =/lib/libc.so.6 =/usr/lib/libc_nonshared.a AS_NEEDED ( =/lib/ld-linux-armhf.so.3 ) )
If you need to change the files often, the easiest solution would be to make a simple script for adjusting the paths in the newly copied files. It should be doable with a few regular expressions…
August 3, 2015 at 18:29 #6785dmitryponvParticipantOk thank you,
I fixed it by setting SysRoot directly in the toolchain-Debug.cmake file
SET(CMAKE_SYSROOT D:/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi)
August 6, 2015 at 04:58 #6805supportKeymasterYes, that should work. Normally if the toolchain is built correctly, it should pick up the sysroot directory from the standard location automatically. If not, specifying –sysroot=xxx (a.k.a. CMAKE_SYSROOT in Cmake) is the way to go.
-
AuthorPosts
- You must be logged in to reply to this topic.