Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コード再利用のしくみ ライブラリ
Search
Satoru Takeuchi
PRO
September 29, 2024
Technology
3
120
コード再利用のしくみ ライブラリ
以下動画のテキストです。
https://youtu.be/Su6LnDaJOxM
Satoru Takeuchi
PRO
September 29, 2024
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Rook: Intro and Deep Dive With Ceph
sat
PRO
1
110
会社員しながら本を書いてきた知見の共有
sat
PRO
3
790
デバイスにアクセスするデバイスファイル
sat
PRO
1
38
ファイルシステムのデータを ブロックデバイスへの操作で変更
sat
PRO
1
32
デバイスドライバ
sat
PRO
0
49
マルチスレッドの実現方法 ~カーネルスレッドとユーザスレッド~
sat
PRO
2
120
共有メモリ
sat
PRO
3
71
マルチスレッドプログラム
sat
PRO
3
59
Linuxのブートプロセス initramfs編
sat
PRO
2
89
Other Decks in Technology
See All in Technology
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
130
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
150
「Chatwork」のEKS環境を支えるhelmfileを使用したマニフェスト管理術
hanayo04
1
240
インフラ寄りSREの生存戦略
sansantech
PRO
9
3.4k
推し書籍📚 / Books and a QA Engineer
ak1210
0
120
Claude Code に プロジェクト管理やらせたみた
unson
8
4.9k
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
200
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
290
SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs
shin1988
2
1.5k
60以上のプロダクトを持つ組織における開発者体験向上への取り組み - チームAPIとBackstageで構築する組織の可視化基盤 - / sre next 2025 Efforts to Improve Developer Experience in an Organization with Over 60 Products
vtryo
3
980
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
510
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
5
2.1k
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Scaling GitHub
holman
460
140k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
How GitHub (no longer) Works
holman
314
140k
Producing Creativity
orderedlist
PRO
346
40k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
970
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Transcript
コード再利用のしくみ ライブラリ Sep. 29th, 2024 Satoru Takeuchi X: satoru_takeuchi 1
はじめに • 「ライブラリ」という、プログラムのコードをまとめて再利用可能にした塊について説 明 • 注意 ◦ ライブラリには実行ファイルと同様、コードとデータ両方が入っているが、説明を簡略化するため コードをどう扱うかのみ説明する 2
ライブラリとは • 多くの人が使うコードを一つにまとめてファイル化したもの • 有名どころ: GNUのCライブラリ、glibc ◦ 標準Cライブラリ+その他山盛りの便利コード • 実行ファイルとの違い
◦ ライブラリファイルを直接実行するわけではない ◦ 実行ファイル内のコードから何らかの形でライブラリのコードを呼ぶ • 「静的ライブラリ」と「動的ライブラリ」の2種類がある 3
静的ライブラリと共有(動的)ライブラリ • 静的ライブラリ ◦ 実行ファイルにライブラリのコードを組み込む ◦ ライブラリが提供する関数の中から、実行ファイルが使うものだけ組み込む ◦ 拡張子は”.a” •
共有(動的)ライブラリ ◦ 実行ファイルには「ライブラリ内の関数を呼び出す」という情報だけ記憶 ◦ 実行ファイルから作ったプロセスのメモリにライブラリのコードを「動的」にマップしてから呼び出す ◦ 同じライブラリを複数の実行ファイルから実行時に「共有」できる ◦ 拡張子は”.so” 4
こういうソースファイルがあった場合… 5 main() { foo() } main.c foo() { …
} bar() { … } foo.c 呼ぶ
静的ライブラリの場合 6 main() { foo() } main.c foo() { …
} bar() { } foo.c main()のコード main.o foo()のコード libfoo.a main()のコード main (実行ファイル) リンク コンパイル コンパイル&静的ライブラリ化 mainプロセスのメモリ空間 bar()のコード foo()のコード main()のコード foo()のコード map 呼ぶ 呼ぶ • 実行前にリンク(静的リンク) • 使用する関数だけをリンク可能
共有(動的)ライブラリの場合 7 main() { foo() } main.c foo() { …
} bar() { } foo.c main()のコード main.o foo()のコード libfoo.so main()のコード main (実行ファイル) リンク コンパイル コンパイル&共有ライブラリ化 mainプロセスのメモリ空間 bar()のコード main()のコード foo()のコード map 呼ぶ 呼ぶ bar()のコード libfoo.soを動的 リンクしていると いう情報 実行開始後にリンク(動的リンク)
実行ファイルのサイズ • 静的ライブラリ ◦ ライブラリ内のコード (の一部)をコピーするので、一般に大きくなる • 共有(動的)ライブラリ ◦ 「実行時にライブラリを動的リンクすべし」というメタデータだけを持ち、ライブラリ内のコードそのも
のは持たないので、一般に小さくなる 8 main()のコード main (実行ファイル) foo()のコード main()のコード main (実行ファイル) libfoo.soを動的 リンクしていると いう情報 静的ライブラリの場合 共有ライブラリの場合 一般に大きい 一般に小さい
ライブラリ変更の実行ファイルへの影響 • 静的ライブラリ ◦ ライブラリ修正後に再リンクした際に実行ファイルに影響が出る • 共有(動的)ライブラリ ◦ ライブラリ変更後、即座に実行ファイルに影響が出る ◦
変更の影響がライブラリを使用する全実行ファイルに及ぶので管理が大変 9 静的ライブラリの場合 共有ライブラリの場合 main()のコード main (実行ファイル) foo()のコード (バグ未修正) foo()のコード (バグ修正済) libfoo.a bar()のコード main()のコード main (実行ファイル) libfoo.soを動的 リンクしていると いう情報 foo()のコード (バグ修正済) libfoo.so bar()のコード
ライブラリファイル破損時の実行ファイルへの影響 • 静的ライブラリ ◦ 無い • 共有(動的)ライブラリ ◦ プロセスを起動してもライブラリの関数が使えないため、機能しない 10
main()のコード main (実行ファイル) foo()のコード foo()のコード libfoo.a bar()のコード あっそ 静的ライブラリの場合 共有ライブラリの場合 foo()のコード libfoo.so bar()のコード main()のコード main (実行ファイル) libfoo.soを動的 リンクしていると いう情報 死んだ! 死んだ! 俺も死んだ! リンク後はlibfoo.aに関係ない
ライセンスの観点 • ライブラリを動的リンクするか静的リンクするかで扱いが異なるライセンスがある ◦ 例: LGPL • とても難しい話なので詳しいことは省略 • 興味があればLGPLの全文を読んでください
◦ https://www.gnu.org/licenses/lgpl-3.0.html.en 11
使い分けは? • 長短あるので、どっちも使われている • 好きなのを使えばいい • 全体的には共有ライブラリのほうが広く使われている(主観) ◦ 静的ライブラリを使うよりサイズが圧倒的に小さくて済む ◦
ただし、実行ファイルが特定バージョンのライブラリでしか動かないケースを避けるために、実行 ファイルと共有ライブラリを同梱して提供する、本末転倒なケースもある • コンテナ環境では静的ライブラリによって作られたシングルバイナリが人気 ◦ アプリケーションコンテナでは共有ライブラリの利点を活かしにくい 12
まとめ • ライブラリはプログラムのコードをまとめて再利用可能にした塊 • 静的ライブラリ、共有(動的)ライブラリの二種類がある • 長短あるので好きなのを使えばよい 13