分类 编译 下的文章
MSVC LNK4099警告的分析与解决
https://www.cnblogs.com/fqucuo/p/4887083.html
问题出在Debug配置的-Zi
选项上。这个选项用于生成目标项目的调试符号。
我产生该警告的过程是,使用CMake配置第三方项目,编译并安装后,删除了编译时的文件夹。
因而猜测,调试符号并不是嵌入到可执行文件(或者库)里的。
MSVC应该是在链接静态库文件的时候,根据写在文件里的信息去寻找(应该也是PATH里的)对应的符号数据库文件吧。(猜测一下,那岂不是把pdb文件复制到lib对应目录下就好了么)
解决方法之一如引用中所说,删除-Zi
选项,不生成额外的调试文件,就可以避免MSVC找不到对应的符号文件而报出的警告。
另一个解决方法,个人认为,如果不是在第三方库的初学阶段,可以考虑将该库的源码添加至项目中,作为主项目的依赖随项目一起编译,然后配置一下输出目录和输出文件名和主项目在同一目录即可。这样至少项目树结构会显得清晰一些。(应该不会有人不知道在没有更新目标target
的选项或是源文件的情况下,VS是可以自动跳过该目标的重新编译的吧)
fedora下编译qcef
最新版的网易云音乐(1.2.1)使用到了deepin自己编写的qcef
,该组建的功能是为第三方软件提供内嵌chrome浏览器的支持。由于是deepin自己写的,dnf里面还没有形成相应的包,所以需要自己编译。
安装了qt库之后,使用cmake开始编译,遇到了这么一个问题:
fatal error: QtGui/private/qguiapplication_p.h not found
#include <QtGui/private/qguiapplication_p.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
安装了qt5的devel包也没用。后来发现private headers被放在了这么一个奇怪的包里:qt5-qtbase-private-devel
安装完这个包,编译继续,正常完成,网易云音乐可以使用。
此外,ubuntu包里的libs就可以删除了,因为可以通过在系统里用dnf手动杆状需要的依赖库。
数据文件可以通过ar x
命令解压,然后在里面的data.tar.gz
里。
LLVM 7.1.0 gnueabihf版本编译记录
LLVM连同组件一起编译
对LLVM有初步了解的话,会发现LLVM可以被描述为编译器的“中后端”。也就是说,LLVM本身不是一个完整的编译器,需要与编译器前端等组件配合使用才能完成完整的编译过程。作为可选组件形式与LLVM一同发布的配件就有配置的讲究了。 根据CMakeList文件对组件的配置,加上网上其他人对于编译过程的总结,对组件及其位置罗列如下:
文件名 | 对应组件 | 对应位置 |
---|---|---|
llvm- |
LLVM本体 | ./ |
cfe- |
Clang | ./tools/clang |
compiler-rt- |
Compiler-RT | ./projects/compiler-rt |
libcxx- |
libcxx | ./projects/libcxx |
libcxxabi- |
libcxxabi | ./projects/libcxxabi |
libunwind- |
libunwind | ./projects/libunwind |
lld- |
LLVM连接器 | ./tools/lld |
lldb- |
LLVM调试器 | ./tools/lldb |
openmp- |
OpenMP支持 | ./projects/openmp |
polly- |
(暂时不懂) | ./tools/polly |
clang-tools-extra- |
Clang附加工具 | ./tools/clang/tools/extra |
test-suite- |
测试程序(相当大) | ./projects/test-suite |
编译时遇到错误:r7 cannot be used in asm here
https://tls.mbed.org/kb/development/arm-thumb-error-r7-cannot-be-used-in-asm-here
根据上述网站叙述,该问题在于gcc对于arm处理器中寄存器的使用方式与arm自身对编译过程的优化中产生了冲突。arm优化的函数在汇编中显式地使用了编号为r7
的寄存器,而在不经优化的情况下,r7
被gcc用作帧指针寄存器,不允许被显示地用作其他用途,从而报错。
在解决这个问题时,发现另一个问题:理论情况来说,发布的稳定版的软件源码在编译时会默认设置为发布版本Release
,在该模式下,编译器将会对目标软件进行大幅优化以加快运行速度(比如常见的开启-O2
或-O3
选项),删除不必要的调试信息从而缩小软件大小。而LLVM却将其默认设置为了调试版本Debug
,在该模式下,将保留较多的源代码信息,能够在出错时较好地帮助开发人员进行调试,也会相比发布版本有着更加接近原代码的二进制逻辑过程,而这也正是上面在直接编译LLVM时遇到错误的原因。
因而解决方法十分清晰了:将CMake中决定编译版本的参数设置为Release即可。
cd /path/to/llvm/src
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
然后再加上其他需要的参数配置完以后,使用make进行编译即可。
若是只想解决该问题并编译调试版本的话,在编译器参数中加上-fomit-frame-pointer
选项即可。
VS2019+CUDA9.2
-
把
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\extras\visual_studio_integration\MSBuildExtensions
下的文件复制到C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\BuildCustomizations
中 - 编辑
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.h
的133-135行,强行添加对新版本VC++的支持。把133行的1913改成1921,要是不怕出事可以直接注释掉整个if。我的个人修改方法:在修改133行的同时,139行插入
#elif _MSC_VER == 1921
#pragma message("support for Microsoft Visual Studio 2019 is unofficial!")
用于验证修改是否有效。
有一点要注意的是,CUDA若是安装在默认的X:\Program Files
目录下的话,修改其中的文件通常需要管理员权限。而我使用的gedit会很神奇地在没有权限的时候(即以普通用户权限保存文件),不知道自动在哪创建一个同名副本保存,并且还会每次贴心地读取副本。。。我一直以为是哪里缓存的问题,直到重启电脑发现文件变回原样才想起来。。。所以说在权限问题上尽量要清晰,不要偷懒或者马虎。