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
130
コード再利用のしくみ ライブラリ
以下動画のテキストです。
https://youtu.be/Su6LnDaJOxM
Satoru Takeuchi
PRO
September 29, 2024
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
「Linux」という言葉が指すもの
sat
PRO
4
150
APIとABIの違い
sat
PRO
5
63
ファイルシステムへのアクセス方法
sat
PRO
0
29
ファイルシステム
sat
PRO
1
36
低レイヤソフトウェア技術者が YouTuberとして食っていこうとした話
sat
PRO
7
6.1k
ポーリングと割り込み
sat
PRO
1
82
Rook: Intro and Deep Dive With Ceph
sat
PRO
1
140
会社員しながら本を書いてきた知見の共有
sat
PRO
3
890
デバイスにアクセスするデバイスファイル
sat
PRO
1
64
Other Decks in Technology
See All in Technology
組織を巻き込む大規模プラットフォーム移行戦略 〜50+サービスのマルチリージョン・マルチプロダクト化で学んだステークホルダー協働の実践〜 / Platform migration strategy engaging all stakeholders
toshi0607
2
250
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
22
12k
エンジニアがデザインまで担うための AI駆動UIデザイン/フロントエンド開発実践
kitami
2
110
Bedrock で検索エージェントを再現しようとした話
ny7760
2
150
Django's GeneratedField by example - DjangoCon US 2025
pauloxnet
0
160
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
220
Rustから学ぶ 非同期処理の仕組み
skanehira
1
160
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
3
400
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
1k
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
470
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Into the Great Unknown - MozCon
thekraken
40
2k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
We Have a Design System, Now What?
morganepeng
53
7.8k
For a Future-Friendly Web
brad_frost
180
9.9k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Context Engineering - Making Every Token Count
addyosmani
3
64
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Speed Design
sergeychernyshev
32
1.1k
Documentation Writing (for coders)
carmenintech
74
5k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
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