rpath and symbolic links with cross-compile

Sysprogs forums Forums VisualGDB rpath and symbolic links with cross-compile

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #33632
    riots100
    Participant

    We are trying to setup a cross-compile environment with an Nvidia Jetson XavierNX and VisualGDB.  In syncing the Xavier filesystem over to Windows 10 we are getting many errors around the creating of symlinks.  We get “error code 1314”, failed to create symlink.

    I’ve tried running Visual Studio as Administrator with no change in generated errors. The command “mklink” does work successfully on our Windows boxes, so it seems that Windows is not preventing the creation of symlinks, only that the creation of symlinks is failing on syncing with VisualGDB.

    This behavior was noted when we create a new cross-compile project in Visual Studio and when building we get many .so file not found link errors. Generally referencing system libraries needed by our shared objects. I found this blog post from 2013 that exactly describes our issues with a solution.

    However, VisualGDB has already modified the ld.so.conf file in the toolchain sysroot directory according to the above reference blog post. Our solution is to manually list all the sub-dependencies that are throwing the error.

    Please advise on what some possible solutions might be.

    VisualGDB Version 5.6R9 (build 4777)
    Visual Studio 2022 Version 17.4.2

    Thank you.

    #33634
    support
    Keymaster

    Hi,

    No problem, we will try to help you. The symbolic link error could be caused by your antivirus interfering with the Visual Studio process, or by invalid symlinks on the target.

    The easiest way to track it down would be to enable the SysprogsSync logging via Tools->Options->VisualGDB->General->SSH->Log SysprogsSync Transfers. Once you try resynchronizing the directory again, VisualGDB will create a SysprogsSync.log file on the Windows side containing the detailed information about the transfer. Please try focusing on a single symlink that could not be set, and checking:

    1. Whether its value on the Linux side makes sense
    2. Whether the target file/directory got copied to the Windows side
    3. Whether the log file mentions anything particular about that symlink

    If it doesn’t help, please share your findings along with the relevant parts of the log file, and we will try to help you get it working.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.