Linking Symbolic Link Paths to Windows Directory

[dmitryponv]

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\lib

Absolute 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 8 years, 9 months ago by dmitryponv.
• This topic was modified 8 years, 9 months ago by dmitryponv.

[support]

Hi,

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…

[dmitryponv]

Ok 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)

[support]

Yes, 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.

[Author]

Posts