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
150
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
コード再利用のしくみ ライブラリ
以下動画のテキストです。
https://youtu.be/Su6LnDaJOxM
Satoru Takeuchi
PRO
September 29, 2024
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Machine Check Exception
sat
PRO
2
35
バイナリダンプの模様を読む
sat
PRO
0
68
cpコマンドはディスク上でデータを コピーしないことがある
sat
PRO
3
54
114-ファイルのshallow_copy.pdf
sat
PRO
2
38
113-Btrfsのスナップショット.pdf
sat
PRO
0
16
システム強制終了時にファイルシステムの整合性を保つ~ コピーオンライト編 ~
sat
PRO
0
59
システム強制終了時に ファイルシステムの整合性を保つ ~ ジャーナリング編 ~
sat
PRO
2
63
ファイルシステムの整合性を回復するfsck
sat
PRO
1
65
小学校5,6年生向けキャリア教育 大人になるまでの道
sat
PRO
8
5.3k
Other Decks in Technology
See All in Technology
kintone の AI コワーカーを、 Anthropic にエージェントを"ホストさせて"作った話 #devkinmeetup
sugimomoto
0
110
穢れた技術選定について
watany
9
700
Data + AI Summit 2026 イベントレポート: 「AIがビジネスで意思決定するデータ基盤」へ
nek0128
0
140
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
630
Amazon EVS で VCF 9.0 / 9.1 のサポート開始まとめ
mtoyoda
0
300
AI時代の EM への処方箋
staka121
PRO
0
140
SRE Next 2026 何でも屋からの脱却
bto
0
700
非定型なドキュメントを効率よくリファクタする 〜えぇ!?仕様書27本の移行が1日で終わったって!?〜
subroh0508
2
390
型は壁、Rustでもバグを直すな、表現できなくせよ
nwiizo
13
2k
しくみを学んで使いこなそう GitHub Copilot app
torumakabe
2
240
しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE
kanny
13
6.1k
環境凍結という Toil を倒す -セルフサービス型 Ephemeral テスト環境の 設計と実践
shirouz
1
2.4k
Featured
See All Featured
Fireside Chat
paigeccino
42
4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
750
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
290
For a Future-Friendly Web
brad_frost
183
10k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.6k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
370
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
220
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