我之前碰到过一模一样的问题，折腾了半天终于搞明白根源：CodeLLDB调试时的环境变量和你正常运行、用GDB调试时不一样，导致动态链接器找不到你的C共享库。下面给你几个亲测有效的解决办法：

方法一：在launch.json里手动指定库路径 #

CodeLLDB默认不会继承你终端里的环境变量，所以得手动把共享库所在目录加到LD_LIBRARY_PATH（Linux）或DYLD_LIBRARY_PATH（macOS）里：

1. 打开VS Code的调试面板，点击「创建launch.json文件」，选择LLDB环境
2. 在生成的配置里，给configurations节点添加env字段，把你的.so所在目录填进去：

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug X executable",
            "program": "${workspaceFolder}/target/debug/<你的可执行文件名>",
            "args": [],
            "cwd": "${workspaceFolder}",
            "env": {
                "LD_LIBRARY_PATH": "${workspaceFolder}/path/to/your/shared/lib:${env:LD_LIBRARY_PATH}"
                // macOS用户把LD_LIBRARY_PATH换成DYLD_LIBRARY_PATH
            }
        }
    ]
}

记得把path/to/your/shared/lib替换成你的.so实际所在的目录，这样动态链接器就能准确定位到它了。

方法二：构建时自动复制共享库到可执行目录 #

如果不想每次调试都配置环境变量，可以在构建脚本里自动把.so复制到target/debug目录，这样CodeLLDB不用额外设置也能找到：

在你的crate X的build.rs里添加这段代码：

use std::fs;
use std::path::Path;

fn main() {
    // 替换成你的C共享库的实际路径
    let shared_lib_src = Path::new("/absolute/path/to/your/library.so");
    // 获取target/debug目录路径
    let target_debug_dir = Path::new(env!("CARGO_TARGET_DIR")).join("debug");

    // 确保目标目录存在
    if !target_debug_dir.exists() {
        fs::create_dir_all(&target_debug_dir).expect("Failed to create target debug directory");
    }

    // 复制共享库到目标目录
    fs::copy(shared_lib_src, target_debug_dir.join("library.so"))
        .expect("Failed to copy shared library to target directory");
}

这样每次cargo build时，你的C共享库都会自动同步到可执行文件所在的目录，调试时自然不会找不到。

方法三：检查CodeLLDB的工作目录 #

有时候是CodeLLDB的工作目录设置不对，导致相对路径的.so无法被解析。确保launch.json里的cwd字段值是${workspaceFolder}（你的项目根目录），这样如果你的.so是相对于项目根目录存放的，就能正确被找到。

为什么GDB能正常工作？ #

因为你在终端里运行GDB时，shell已经帮你设置好了正确的LD_LIBRARY_PATH（或者你的.so本来就在系统默认的共享库搜索路径里），但CodeLLDB是作为独立进程启动的，不会继承这些终端环境变量，所以才会出现“GDB正常、CodeLLDB报错”的差异。

内容的提问来源于stack exchange，提问作者DaPurr