一件事,如果你做得太好,然后一来二去不注意就无意的开始卖弄起来,这样一来就不好了。
为了看mysql5.7的源码,就需要在windows中生成visual studio工程文件,然后编译通过后调试进行逐步查看代码。(至于详细步骤我在文章《死磕mysql源码前奏》中介绍了)
但是,在win10操作系统里面,我通过cmake(版本3.15.2)生成visual studio工程后,visual studio中生成解决方案时,提示报错:
137>LINK : fatal error LNK1181: 无法打开输入文件“..\..\..\archive_output_directory\Debug\sql.lib”137>已完成生成项目“pfs_connect_attr-t.vcxproj”的操作 - 失败。
由于sql.lib没生成,导致mysqld.lib也无法生成,后续日志中也报错:
149>LINK : fatal error LNK1181: 无法打开输入文件“..\..\sql\Debug\mysqld.lib”
150>Running C++ protocol buffer compiler (lite) on E:/database/mysql/srccode/mysql-5.7.27/rapid/plugin/x/protocol/mysqlx_datatypes.proto
149>已完成生成项目“mysql_no_login.vcxproj”的操作 - 失败。
148>LINK : fatal error LNK1181: 无法打开输入文件“Debug\mysqld.lib”
问题出现时,一开始我以为是cmake问题,于是我把cmake版本由3.8.2升级到了cmake3.15.2,并用cmake-ui及命令行生成工程文件。
图形界面:
命令行:
E:\compileSoft\cmake-3.15.2-win64-x64\bin\cmake .. -DWITH_BOOST="E:\database\mysql\srccode\mysql-5.7.27\boost\boost_1_59_0.tar.gz" -G "Visual Studio 16 2019 Win64" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DWITH_MSAN=ON
然而,并没什么用!
在visual studio解决方案里面,错误还是一样!
于是我又折腾起来了,我把本机的visual studio 2015卸载了,重新下载了一个visual studio 2019 community版本。
但是,结果是残酷的!错误还是存在!
看来还是要老老实实去看日志。于是,我首先对sql项目块进行生成解决方案,查看具体报错信息:
34>E:\database\mysql\srccode\mysql-5.7.27\sql\sql_lex_hash.cc(17,10): error C1083: 无法打开包括文件: “lex_hash.h”: No such file or directory
可以看到,在生成sql.lib过程中,提示找不到lex_hash.h文件。于是我进入源码包中,查看文件,发现确实没有(并且在工程文件中也没有):
打开sql_lex_hash.cc文件,查看源码:
#include "lex_hash.h"
#include "sql_lex_hash.h"
#include "lex.h"
const Lex_hash Lex_hash::sql_keywords(sql_keywords_map, sql_keywords_max_len);
const Lex_hash Lex_hash::sql_keywords_and_funcs(sql_keywords_and_funcs_map,
sql_keywords_and_funcs_max_len);
const Lex_hash Lex_hash::hint_keywords(hint_keywords_map,
hint_keywords_max_len);
看这个源码,我觉得很奇怪,为什么有了sql_lex_hash.h头文件,还包含一个lex_hash.h头文件。
我看了下sql_lex_hash.cc源码,我试着把lex_hash.h头进行注释,但是发现sql_keywords函数报错,看来不行。
没办法,百度,发现根本没有类似错误。
于是我怀疑难道是bug,于是我进入mysql官网,搜索lex_hash.h的信息。最终我搜索到一些关键信息:
Description:
Our software-distribution system symlinks all source-files from another location (read-only filesystem) before build. During build of MySQL 4.1.18 on Solaris 8, I get an error when gen_lex_hash tries to overwrite lex_hash.h because lex_hash.h is a symlink to a read-only file. From sql/Makefile:
lex_hash.h: gen_lex_hash$(EXEEXT)
./gen_lex_hash$(EXEEXT) > $@
You should not overwrite the source-files during build.
How to repeat:
Unpack the MySQL source tar.gz-file and make all the file read-only. Create a source-tree where all the files (not directories) are symlinks to the original unpacked read-only source-tree. Now try to build MySQL.
Suggested fix:
If it is neccessary to create a new file for lex_hash.h during build, create it with a name that is not an existing file already.
从中我了解到,原来lex_hash.h头文件是在build过程中通过gen_lex_hash进行重写的。
自己本地的lex_hash.h文件一直没生成,是因为自己没有进行build操作,补充build操作:
E:\compileSoft\cmake-3.15.2-win64-x64\bin\cmake --build . --config relwithdebinfo --target package
这时,我发现本地生成了windows环境下的mysql运行包:
lex_hash.h文件也有了
最后,自己本地visual studio正确生成了解决方案,可以进行源码调试了。
事后,自己分析自己折腾这么久的根本原因还是由于自己知识储备不足,对c/c++和相应环境不熟悉。只能对自己说一句:“学无止境”了!
欢迎大家关注以下公众号进行数据库方面知识探讨: