C++(报错记录)

一、配置头文件和库文件(引自以下文章,这里做一下记录)Visual Studio 2017 第三方依赖设置,附加依赖项和附加库目录_链巨人的博客-优快云博客_vs2017 附加依赖项

1、添加工程的头文件目录:
工程---属性---配置属性---c/c++---常规---附加包含目录:加上头文件存放目录。
对应相应的头文件夹(include文件夹),里面存放的是.h头文件; 
项目名右键 -- properties -- c/c++ -- General -- Additional Include Directories

2、添加文件引用的lib静态库路径:
工程---属性---配置属性---链接器---常规---附加库目录:加上lib文件存放目录。
对应本例中的lib文件夹。里面存放的是.lib文件;
项目名右键 -- properties -- Linker -- General -- Link Library Dependencies

3、然后添加工程引用的lib文件名:
工程---属性---配置属性---链接器---输入---附加依赖项:加上lib文件名。 
项目名右键 -- properties -- Linker -- Input -- Additional Dependencies.

二、报错

1、缺少lib文件,检查lib文件是否配对。

2、若该lib没有在属性页中找到,则有可能时继承而来,依次打开,试图——属性管理器——对应的DeBug64,看看下面属性页里面哪个里面引用了,删除重新配置有可能解决。

3、

C2440:属性->C/C++->语言->符合模式->否

C4996:属性->C/C++->常规->SDL检测->否

4、 重定义默认参数 : 参数 1

检查是不是定义和声明同时指定了默认参数,仅需声明指定就行

5、连接什么什么的  有可能是后面定义改了参数,前面声明没改

### 可能的原因分析 在 C++ 使用 CMake 构建项目时,如果遇到错误提示 `'must be under the source or output directories'`,通常是因为某些文件路径不符合 CMake 的构建规则。CMake 要求所有的生成文件(如目标文件 `.o` 或最终的可执行文件)都必须位于项目的源目录或指定的输出目录下。 以下是可能导致该问题的具体原因: 1. **目标文件路径设置不正确**:CMake 默认会将中间生成的目标文件放在当前工作目录或其他默认位置。如果这些路径不在源码树或指定的二进制输出目录中,则会出现此错误。 2. **未正确配置 `CMAKE_RUNTIME_OUTPUT_DIRECTORY` 和其他输出变量**:如果没有显式定义输出目录,可能会导致生成文件被放置到非法的位置[^1]。 3. **跨平台或多架构编译冲突**:当尝试在一个非标准环境中运行 CMake 时(例如通过 Docker 容器中的交叉编译工具链),也可能引发类似的路径验证失败[^2]。 4. **测试框架特定约束**:像 SPEC CPU 这样的性能评估套件有严格的环境需求;如果脚本未能适配实际操作系统版本或者 GCC 版本差异,也会间接影响正常流程并抛出异常消息[^3]。 ### 解决方法 #### 方法一:调整 CMakeLists.txt 文件 确保所有生成物存放到合法子目录内。可以通过修改 `CMakeLists.txt` 来实现这一点。下面是一个简单的例子展示如何设定统一的输出路径: ```cmake set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin) add_executable(greeter_server greeter_server.cc) target_link_libraries(greeter_server PRIVATE protobuf::libprotobuf) ``` 以上代码片段设置了库和可执行程序的标准存储地点为 `${PROJECT_BINARY_DIR}` 下对应的子文件夹里。 #### 方法二:重新组织构建过程 按照推荐的最佳实践分离源代码与构建产物。具体操作如下所示: ```bash mkdir -p /path/to/your/project/build && cd $_ cmake .. make ``` 这样可以避免污染原始源码仓库的同时满足大多数现代 IDE 对于清晰结构化工程的要求[^2]。 #### 方法三:检查并修正环境变量 对于复杂依赖关系下的大型开源软件包来说,有时需要额外指明一些外部链接选项才能顺利完成整个组装链条。比如,在 ClickHouse 示例中提到过的情况,我们应当确认所使用的 Clang 工具集确实可用,并且调试模式开启有助于定位潜在隐患: ```bash $ mkdir build && cd build $ cmake .. \ -DCMAKE_CXX_COMPILER=$(which clang++) \ -DCMAKE_C_COMPILER=$(which clang) \ -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON $ make VERBOSE=1 ``` 这里增加了 `-D` 参数来强制覆盖默认行为以及启用详细的日志记录以便后续排查任何遗漏之处[^2]。 #### 方法四:针对 SPEC CPU 场景优化 由于 SPEC 提供了一整套预设好的控制参数集合用于标准化评测条件,因此建议严格按照官方文档指示逐步完成初始化准备动作后再启动正式跑分作业。同时注意核实基础镜像是否匹配预期规格——即采用兼容性强的基础发行版作为宿主机容器基座能够有效减少不必要的干扰因素引入风险[^3]: ```bash #!/bin/bash source shrc ulimit -s unlimited runspec --config=gcc41.cfg --tune=all --noreportable --size=test int fp > runspec.log 2>&1 & tail -f runspec.log ``` 另外还需留意是否存在权限不足或者其他资源争抢现象阻碍进程顺利推进下去。 --- ### 总结 综上所述,“must be under the source or output directories”的核心在于合理规划好各个阶段产生的临时数据存放区域边界划分策略。无论是借助高级别的自动化管理机制还是手动干预微调细节部分均需遵循既定原则从而达成稳定可靠的成果交付目的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值