https://www.cnblogs.com/fqucuo/p/4887083.html
问题出在Debug配置的-Zi选项上。这个选项用于生成目标项目的调试符号。
我产生该警告的过程是，使用CMake配置第三方项目，编译并安装后，删除了编译时的文件夹。
因而猜测，调试符号并不是嵌入到可执行文件（或者库）里的。
MSVC应该是在链接静态库文件的时候，根据写在文件里的信息去寻找（应该也是PATH里的）对应的符号数据库文件吧。（猜测一下，那岂不是把pdb文件复制到lib对应目录下就好了么）
解决方法之一如引用中所说，删除-Zi选项，不生成额外的调试文件，就可以避免MSVC找不到对应的符号文件而报出的警告。
另一个解决方法，个人认为，如果不是在第三方库的初学阶段，可以考虑将该库的源码添加至项目中，作为主项目的依赖随项目一起编译，然后配置一下输出目录和输出文件名和主项目在同一目录即可。这样至少项目树结构会显得清晰一些。（应该不会有人不知道在没有更新目标target的选项或是源文件的情况下，VS是可以自动跳过该目标的重新编译的吧）
最新版的网易云音乐（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里。
在国内逛了老半天，都tm是那几篇博客，讲的方法我从f26试到f28，没有一次是成功的（生气）。
然后到国外逛，在Reddit上看到了有不少人在对这个进行讨论。有人直接用nvidia的.run文件安装驱动，然后上bumblebee管理，也有人用rpmfusion里的驱动，也有人用Negativo17的nvidia驱动源。为啥我只给最后一个方式添加链接呢？因为这就是本篇的主角。
至少在我华硕+HM175的笔记本上，使用原生驱动加bumblebee在配置正确的情况下是会直接让电脑死机的，也不知为啥，看到Negativo17这个名字的时候，总有种熟悉感，而且直觉告诉我用了这个一定会配置好。。。
直接上操作了：
/etc/sysconfig/grub中的GRUB_CMDLINE_LINUX变量，如果有与modeset相关的一律删掉，改为rd.driver.blacklist=nouveau用以在开机时不加载会让电脑卡死的nouveau驱动。
在此顺便提一下：nomodeset将不会加载任何驱动，直接使用llvmpipe以兼容方式实现最基本的图形输出；nouveau.modeset=0将会加载但不使用nouveau驱动，若是cpu有核显的话会加载并使用对应的核显驱动。sudo dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.reponvidia-driver，需要使用CUDA的话还需要安装nvidia-driver-cuda和cuda-devel；需要看X Server Settings的安装nvidia-settings。
GPU开发者全家桶：
sudo dnf install nvidia-driver nvidia-driver-cuda cuda-devel nvidia-settings根据作者描述，如果是游戏玩家的话，可能还需要32位的图形库nvidia-driver-libs.i686。
装完就完事了。直接能用。
然后根据作者描述有以下两种情景： 1）使用nvidia的官方闭源驱动：在该场景下能最大程度地发挥GPU的性能，但是所有应用将运行在nvidia GPU上，因而无法关闭； 2）使用nouveau开源驱动：对于GPU的使用可能不是十分充分，但是可以选择是否将应用运行在nvidia GPU上，因而可以从某种程度上节省电能，即在该模式下，允许nvidia GPU休眠。 也就是说，使用Negativo17的驱动源，在目前的Fedora上是无法兼顾性能与能耗的。
（有人在Reddit论坛上提到，nvidia官方的run文件不受linux发行版的包管理器管理，会修改许多文件，可能与其他软件造成冲突；自身的卸载指令也无法完全生效，总之就是卸不干净。。。反正据他们推荐，在好还是用包管理器提供的显卡驱动）
把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会很神奇地在没有权限的时候（即以普通用户权限保存文件），不知道自动在哪创建一个同名副本保存，并且还会每次贴心地读取副本。。。我一直以为是哪里缓存的问题，直到重启电脑发现文件变回原样才想起来。。。所以说在权限问题上尽量要清晰，不要偷懒或者马虎。
由于在配置直接使用网线进行的远程桌面连接时，操作太急，把弹出的提示框直接关掉了。 然后发现在网络管理中心，在同一张网卡、同一个网络下，多出了一个“未识别网络”。这玩意不但碍眼，还导致网络访问速度（甚至成功率）有一定的下降。
在经过长时间的网络搜寻之后，在这个帖子里获得了灵感。在该文中提到，提问者是由于在一张网卡上配置了两个网关，导致Windows会对经由每一个网关的网络连通性进行检测，若是数据包发错了路由，就会无法正常与服务器通讯，出现网络错误。
回想之前的操作过程中，由于急着修改IP地址，忘记网关没有修改了，然后Windows自动为其配置成了多网关模式，而这就导致了上述情况的发生，回去查看连接属性，果然有两个网关。先点选手动分配IP地址，然后删掉那个多余的网关，再重新切换回自动分配模式即可。