Linuxプログラマーが、完成した.so.aライブラリーを使用する代わりに、ライブラリーに依存するソースコードをコンパイルすることを好むのはなぜですか?

バックグラウンド

今朝早くここに来て、WeChatのフロントエンドの学生から挨拶を受け取り、バグを投稿しました。なぜ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時間以上費やした後log4cxxを毎回再コンパイルするのではなく以前にコンパイルしたlog4cxx.sobuild.shスクリプトで直接使用されていることがわかりました。

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プログラマーは依存ライブラリーのソースコードをコンパイルするのが好きなのですか?その理由の1つは、一貫性のない環境が原因で依存ライブラリが見つからないという問題を回避するためだと思います

付録
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は、見つからないことのみを表示します。

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

おすすめ

転載: blog.csdn.net/xmcy001122/article/details/106493004
おすすめ