背景

今天一早过来，企业微信上就收到一个前端同学发来的问好，顺带给我贴了一个bug，为什么mit环境登录不上去了？
在这里插入图片描述
瞬间，我想起来mit环境3台机器为了调试一个功能，都给停掉了，也导致了上面websocket登录不上（PS：android和ios是通过自己开发的负载均衡服务获取动态IP地址登录的，所以不受影响。而web是通过nginx+域名的方式，域名映射的3台机器都停了，肯定就登录不上了。）

赶快掏出自己搭建的jenkins利器，一键部署N台机器，简直不要太爽：
CICD实战——使用Jenkins实现自动化部署和环境隔离

在这里插入图片描述
PS：jenkins的工作原理大概如上图，每次构建都先从github/gitlab拉一份代码，编译后（自己写脚本）就可以分发到需要部署的多台机器上部署（自己写脚本控制）。

1.点击构建
在这里插入图片描述
2.查看控制台结果

我发现一切都正常，但是进程就是没起来，怎么回事？

[root@10-0-59-178 webapps]# ls
online.base.immsgserver.service  online.base.immsgserver.service.202006026

于是，我手动执行了一下：
在这里插入图片描述
为什么找不到 libdb-4.7.so？

[root@10-0-59-178 msg_server]# whereis libdb-4.7.so
libdb-4.7:[root@10-0-59-178 msg_server]#
[root@10-0-59-178 msg_server]# whereis libdb-5.3.so
libdb-5.3: /usr/lib64/libdb-5.3.so

原因

为了查明原因，我用ldd看了一下依赖：
不能运行的机器：
在这里插入图片描述
运行良好的机器：

这是为什么？

最终，花了 1个多小时，我发现在 build.sh 脚本里面是直接使用之前编译好的log4cxx.so，而不是每次重新编译log4cxx。

copy_libs(){
    
    
    # lib
    # 解决jekins发布job编译过长问题，故提前编译好protobuf、log4cxx、hiredis等，节约时间
    cp ${CUR_DIR}/lib/linux/* ${CUR_DIR}/lib/
}

所以，重新编译一下log4cxx即可。ldd看一下编译好的：

[root@10-0-59-231 linux]# ldd liblog4cxx.so
	linux-vdso.so.1 =>  (0x00007ffd36155000)
	libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f8597d0b000)
	libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f8597aab000)
	liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f859789c000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f8597672000)
	libdb-5.3.so => /usr/lib64/libdb-5.3.so (0x00007f85972b2000)

总结

所以，为什么Linux程序员都喜欢编译依赖库的源码呢？我认为其中一个原因就是可以避免因为环境不一致而带来一些依赖库not found的问题。

附录
1.ldd命令查看依赖

ldd msg_server

linux-vdso.so.1 =>  (0x00007fff3d4fc000)
libslog.so => ./libslog.so (0x00007fad6a9be000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fad6a555000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fad6a339000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007fad6a0c7000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fad69dbd000)
libm.so.6 => /lib64/libm.so.6 (0x00007fad69abb000)

2.ldd 只显示 not found：

ldd msg_server |grep "not found"

输出

libdb-4.7.so => not found

3.objdump 反汇编查看缺失依赖库

objdump -x liblog4cxx.so|grep NEEDED

输出

[root@10-0-59-178 msg_server]# objdump -x liblog4cxx.so|grep NEEDED
  NEEDED               libaprutil-1.so.0
  NEEDED               libldap-2.4.so.2
  NEEDED               liblber-2.4.so.2
  NEEDED               libexpat.so.1
  NEEDED               libdb-4.7.so
  NEEDED               libapr-1.so.0
  NEEDED               libpthread.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  NEEDED               libgcc_s.so.1

为什么Linux程序员都喜欢编译依赖库的源码而不是使用成品.so.a库？

背景

原因

总结

猜你喜欢