| 原作者 | ローランド・マクグラス |
|---|---|
| 開発者 | GNU プロジェクト、最も貢献したのは Ulrich Drepper 氏 |
| 初回リリース | 1987年[1] |
| 安定版リリース | 2.40 [2]
/ 2024年7月22日 |
| リポジトリ |
|
| 書かれた | C |
| オペレーティング·システム | Unixライク |
| タイプ | ランタイムライブラリ |
| ライセンス | 2001: LGPL-2.1以降[a] 1992: LGPL-2.0以降[b] |
| Webサイト | このサイトは、 |
GNU C ライブラリ(通称glibc)は、 GNU プロジェクトによるC 標準ライブラリの実装です。アプリケーションで使用するために、Linux カーネルやその他のカーネルのシステム コールのラッパーを提供します。名前に反して、現在ではC++も直接サポートしています(間接的に他のプログラミング言語もサポートしています)。1980 年代にフリー ソフトウェア財団(FSF)によってGNUオペレーティング システム向けに開発が始まりました。
glibc は、 GNU Lesser General Public Licenseに基づいてリリースされたフリーソフトウェアです。[3] GNU C ライブラリプロジェクトは、GNU システムや、Linux をカーネルとして使用する多くのシステムのコアライブラリを提供しています。これらのライブラリは、ISO C11、POSIX.1-2008、BSD 、 OS 固有の API など、重要なAPI を提供します。これらの API には、 open、read、write、malloc、printf、getaddrinfo、dlopen、pthread_create、crypt、login、exitなど の基本的な機能が含まれています。
歴史



glibc プロジェクトは、1987 年の夏に 10 代のころにフリーソフトウェア財団(FSF) で働いていた Roland McGrath によって主に書かれました。 [10] [11] 1988 年 2 月、FSF は glibc がANSI Cで要求される機能をほぼ完成させたと述べました。[12] 1992 年までに、ANSI C-1989 および POSIX.1-1990 の機能が実装され、POSIX.2 の作業が進行中でした。[13] 1995 年 9 月、Ulrich Drepper が glibc に初めて貢献し、1997 年までにほとんどのコミットが彼によって行われました。Drepper は長年にわたってメンテナシップの地位を保持し、2012 年までにプロジェクトへのすべてのコミットの 63% を占めました。[14]
2009年5月にglibcはGitリポジトリに移行されました。[14]
2010年に、GPL非互換のglibcのSun RPC実装によって引き起こされたライセンス問題が解決されました。これは、Sun RPCコンポーネントをBSDライセンスの下で再ライセンスすることで修正されました。[15] [16]
2014年、glibcはs390のABI破損バグに悩まされました。[17]
2017年7月、glibcを開始してから30年後、ローランド・マクグラスは退任を発表し、「名誉メンテナーを宣言し、プロジェクトへの直接的な関与から撤退します。過去数ヶ月、いや過去数年間で、皆さんはもう私を必要としていないことが証明されました」と述べた。[10]
2018年、メンテナーのレイモンド・ニコルソンはglibcのソースコードから中絶に関するジョークを削除した。リチャード・ストールマンがそれを戻すよう要求した後、アレクサンドル・オリヴァがそれを復元した。[18]
2021年には、フリーソフトウェア財団への著作権譲渡要件がプロジェクトから削除されました。[19]
フォークとバリアント
1994年、Linuxカーネルの開発者はglibcを フォークした。そのフォークである「Linux libc」は、1998年頃まで個別に保守されていた。著作権の帰属が不十分だったため、変更をGNU Libcにマージすることができなかった。[20] FSFが1997年1月にglibc 2.0をリリースしたとき、カーネル開発者は、glibc 2.0のPOSIX標準への準拠が優れていたため、Linux libcを中止した。[21] glibc 2.0では、国際化と翻訳がより優れ、IPv6機能、64ビットデータアクセス、マルチスレッドアプリケーション用の機能、将来のバージョン互換性があり、コードの移植性も向上した。[22]最後に使用されたLinux libcのバージョンでは、内部名(soname)libc.so.5が使用されていた。これに続いて、Linux上のglibc 2.xはsoname libc.so.6 [23] [より良いソースが必要]を使用します。
2009年、Debianといくつかの派生版はglibcからその変種[25] eglibcに切り替えた。[26] eglibcはFreescale、MIPS、MontaVista、Wind Riverからなるコンソーシアムによってサポートされていた。[27] eglibcには組み込み用途に適した変更が加えられ、 PowerPC e500などglibcではサポートされていなかったアーキテクチャのサポートも追加された。eglibcのコードはバージョン2.20でglibcに再び統合された。[28] 2014年以降、eglibcは廃止されている。Yocto ProjectとDebianもDebian Jessieのリリース以降glibcに戻っている。[29]
運営委員会
2001年から図書館の開発は委員会によって監督され[30] 、ウルリッヒ・ドレッパー[31]が主な貢献者および保守者として留まりました。運営委員会の設置は世間の論争を巻き起こし、ウルリッヒ・ドレッパーはリチャード・ストールマンによる失敗した敵対的買収策略であると公然と評しました。[32] [33] [34] [35]
2012年3月、運営委員会は解散し、コミュニティ主導の開発プロセスを採用するためにDrepperを解任することを決議し、Ryan Arnold、Maxim Kuvyrkov、Joseph Myers、Carlos O'Donell、Alexandre OlivaがGNUの保守責任を負うことになった(ただし、追加の意思決定権はない)。[36] [37] [38]
機能性
glibc は、Single UNIX 仕様、POSIX (1c、1d、および 1j) で要求される機能と、ISO C11、ISO C99、Berkeley Unix (BSD) インターフェース、System V インターフェース定義(SVID)、およびX/Open 移植性ガイド(XPG)、Issue 4.2 で要求される機能の一部を提供し、XSI (X/Open システム インターフェース) 準拠システムに共通するすべての拡張機能とすべての X/Open UNIX 拡張機能を備えています。
さらに、glibc は、GNU の開発中に有用または必要であると判断された拡張機能も提供します。
サポートされているハードウェアとカーネル
glibc は、多くの異なるカーネルや異なるハードウェアアーキテクチャを実行するシステムで使用されます。最も一般的な用途は、x86ハードウェア上でLinuxカーネルを使用するシステムですが、公式にサポートされているハードウェア[39]には、ARM、ARC、C-SKY、DEC Alpha、IA-64、Motorola m68k、MicroBlaze、MIPS、Nios II、PA-RISC、PowerPC、RISC-V、s390、SPARC、x86 (古いバージョンはTILE をサポート) が含まれます。HurdカーネルとLinuxカーネルを公式にサポートしています。さらに、FreeBSDとNetBSD (それぞれDebian GNU/kFreeBSDとDebian GNU/NetBSDシステムが構築されているカーネル)のカーネルで動作する、大幅にパッチを当てたバージョンや、OpenSolarisのフォークバージョンもあります。 [ 40 ] BeOSとHaikuでも(編集された形式で) libroot.soという名前で使用されています。[41]
小型デバイスでの使用
glibcは、過去にLinus Torvalds [42]や組み込みLinuxプログラマーなどから「肥大化」し他のライブラリよりも遅いと批判されてきた。このため、より小さなフットプリントを重視したいくつかの代替C標準ライブラリが作成されてきた。しかし、多くの小型デバイスプロジェクトでは、アプリケーションのサポート、標準への準拠、完全性のため、より小さな代替ライブラリよりもGNU libcを使用している。例としては、Openmoko [43]やiPaqハンドヘルド用のFamiliar Linux ( GPEディスプレイソフトウェアを使用する場合)などがある。[44]
安全な文字列関数
glibcはC11で定義された境界チェックインターフェースを実装しておらず、strlcpyとstrlcat [45] [46]も2023年まで実装しなかった。その理由は、「これらの関数は実際には問題を引き起こす可能性がある。なぜなら、その意図された使用法は、暗黙的なデータ切り捨てを促し、複雑さと非効率性を増加させ、宛先でのバッファオーバーランをすべて防ぐわけではないからである」というものである。 [47] FAQでは、境界チェックインターフェースはISO標準ではオプションであり、snprintfが代替として利用可能であると指摘されている。[47]
互換性レイヤー
他のエコシステム向けに書かれたプログラムを glibc インターフェースを提供するシステムで実行できるようにする互換性レイヤー(「shim 」)があります。これには、 Android のBionicの互換性レイヤーであるlibhybrisや、Windows APIから glibc や Unix 系システムで利用可能な他のネイティブ API への互換性レイヤーとみなせる Wine が含まれます。
参照
注記
- ^ LGPL-2.1以降、2001-07-06以降、バージョン2.2.4。[3] [4]
- ^ LGPL-2.0以降、1992年から2001年7月5日まで。バージョン1.04?から2.2.3。[5] [6]
参考文献
- ^ Corbet, Jonathan (2012年3月28日). 「GNU libcの転換点」. LWN.net. 2016年4月23日時点のオリジナルよりアーカイブ。 2012年4月5日閲覧。
- ^ 「GNU C ライブラリ バージョン 2.40 が利用可能になりました」。2024 年 7 月 22 日。2024年7 月 23 日閲覧。
- ^ ab "sourceware.org Git – glibc.git/blob – Makefile". sourceware.org . 2021年6月10日時点のオリジナルよりアーカイブ。 2021年6月10日閲覧。
ヘッダーにLGPL-2.1以降
- ^ 「sourceware.org Git – glibc.git/commit – LGPL v.2.1 へのアップデート」。sourceware.org。2001年7月6日。2021年6月10日時点のオリジナルよりアーカイブ。 2021年6月10日閲覧。
ヘッダーに LGPL-2.1-or-later と
記載 - ^ “glibc-1.04.tar.Z”. 1992年9月4日. 2021年12月22日時点のオリジナルよりアーカイブ。2021年12月22日閲覧。
- ^ 「sourceware.org Git – glibc.git/commit – 初期インポート: Makefile」。sourceware.org。1995年2月18日。2021年6月10日時点のオリジナルよりアーカイブ。 2021年6月10日閲覧。
ヘッダーにLGPL-2.0以降
- ^ “sourceware.org Git – glibc.git/blob – NEWS”. 2022年3月21日時点のオリジナルよりアーカイブ。2019年4月26日閲覧。
- ^ “sourceware.org Git – glibc.git/blob – NEWS”. 2019年9月26日時点のオリジナルよりアーカイブ。2019年4月26日閲覧。
- ^ “GNU C ライブラリ バージョン 2.32 が利用可能になりました”. sourceware.org . 2020 年 9 月 28 日時点のオリジナルよりアーカイブ。2020 年8 月 13 日閲覧。
- ^ ab “Roland McGrath bows out as glibc Maintainer [LWN.net]”. lwn.net . 2017年7月7日. 2020年8月1日時点のオリジナルよりアーカイブ。2017年7月8日閲覧。
- ^ Chirgwin, Richard (2017年7月10日). 「Roland McGrathが30年間務めたglibcのメンテナーを退任」The Register . Situation Publishing. 2024年3月7日時点のオリジナルよりアーカイブ。 2024年6月1日閲覧。
- ^ 「GNU's Bulletin, vol. 1 no. 4, February, 1988」。2016年4月16日時点のオリジナルよりアーカイブ。 2014年4月16日閲覧。
ほとんどのライブラリは完成しています。Roland McGrath [...] は、ANSI C ライブラリ関数のほぼ完全なセットを持っています。この春には準備が整うことを期待しています。
- ^ 「GNU の速報、第 1 巻第 12 号」。2016 年 3 月 11 日時点のオリジナルからアーカイブ。2014 年4 月 16 日閲覧。
現在は ANSI C-1989 および POSIX.1-1990 のすべての関数が含まれており、POSIX.2 および Unix 関数 (BSD および System V) の作業が進行中です。
- ^ ab Corbet, Jonathan (2012年3月28日). 「GNU libcの転換点」. LWN.net. 2016年4月23日時点のオリジナルよりアーカイブ。 2012年4月5日閲覧。
プロジェクトのgitリポジトリ(1995年までの変更を含む)で見つかった約19,000件のコミットのうち、12,000件以上がUlrichによるものでした。
- ^ “Glibc がついにフリーソフトウェアに – The H Open: News and Features”. H-online . 2022年3月21日時点のオリジナルよりアーカイブ。2021年9月19日閲覧。
- ^ Phipps, Simon (2010年9月2日). 「Gnu/Linux: ついに、本当にフリーソフトウェアに」. InfoWorld . 2021年10月28日時点のオリジナルよりアーカイブ。 2021年9月19日閲覧。
- ^ Corbet, Jonathan. 「glibc s390 ABI の中断 [LWN.net]」。LWN.net。2022年3月17日時点のオリジナルよりアーカイブ。2022年3月17日閲覧。
- ^ Claburn, Thomas. 「Glibc の「中絶ジョーク」の diff tiff でリチャード・ストールマンが激怒」The Register。2023年1月17日時点のオリジナルよりアーカイブ。 2023年1月17日閲覧。
- ^ Halfacree, Gareth. 「オープンソースプロジェクトのglibcとgnulibは、フリーソフトウェア財団との著作権関係を断つことを検討している」The Register。2023年1月17日時点のオリジナルよりアーカイブ。 2023年1月17日閲覧。
- ^ “glibcとLinux libcの歴史”.フリーソフトウェアマガジン. 2021年9月26日時点のオリジナルよりアーカイブ。2021年5月10日閲覧。
- ^ 「フォーク:あなたにも起こり得る」 2000年10月24日。2009年9月15日時点のオリジナルよりアーカイブ。GNU
LIBCとLinux LIBCの分裂 -- Linuxが安定するまで何年も続き、その後フォークは1つのプロジェクトに再統合されました。
- ^ Lee, Elliot (1998 年 7 月 9 日)。「glibc 2.x とレガシー システム ライブラリの技術的比較」。2004 年 4 月 11 日時点のオリジナルよりアーカイブ。
- ^ Moen, Rick (2021年5月20日) [1999年11月14日]. 「フォークの恐怖に関するエッセイ」. linuxmafia.com . 6. glibc --> Linux libc --> glibc. 2023年11月27日時点のオリジナルよりアーカイブ。
- ^ “EGLIBC: FAQ”. eglibc.org . 2012年3月17日時点のオリジナルよりアーカイブ。 2021年9月16日閲覧。
- ^ eglibcの開発者は、eglibcはglibcのフォークではなく、上流のglibcプロジェクトからのパッチを受け入れる変種であることを強調した。[24]
- ^ Vaduva, Alexandru (2016). Linux: 組み込み開発: Linux のパワーを活用して魅力的で強力な組み込み Linux プロジェクトを開発する: 3 つのモジュールからなるコース。Alex Gonzalez、Chris Simmonds。バーミンガム、イギリス: Packt Publishing。p. 24。ISBN 978-1-78712-445-5. OCLC 960471438.
- ^ ジュリアス、スティベルト (2009 年 5 月 6 日)。 「Debian wechselt zur Eglibc」。ゴーレムで。 2021年9月16日のオリジナルからアーカイブ。2021 年9 月 16 日に取得。
- ^ Simmonds, Chris (2017). 組み込み Linux プログラミングの習得: 組み込み Linux の可能性を最大限に引き出す (第 2 版). バーミンガム、イギリス. p. 26. ISBN 978-1-78728-885-0. OCLC 995052708.
{{cite book}}: CS1 メンテナンス: 場所が見つかりません 発行者 (リンク) - ^ Vaduva, Alexandru (2015). Yocto プロジェクトを使用した組み込み Linux の学習: Yocto プロジェクト コンポーネントを使用して強力な組み込み Linux システムを開発する。バーミンガム、英国。p. 29。ISBN 978-1-78439-519-3. OCLC 914797028.
{{cite book}}: CS1 メンテナンス: 場所が見つかりません 発行者 (リンク) - ^ 「glibc ホームページ」。2016 年 4 月 22 日時点のオリジナルよりアーカイブ。2014年4 月 16 日閲覧。2001
年に GNU C ライブラリ運営委員会が結成され、現在は Mark Brown、Paul Eggert、Andreas Jaeger、Jakub Jelinek、Roland McGrath、Andreas Schwab で構成されています。
- ^ “Ulrich Drepper”. LinkedIn. 2014年9月10日時点のオリジナルよりアーカイブ。2012年6月13日閲覧。
- ^ オンライン、ヘイセ (2001 年 8 月 19 日)。 「オープンソース - Entwickler kritisiert Stallman」。heise オンライン(ドイツ語)。 2021年9月16日のオリジナルからアーカイブ。2021 年9 月 16 日に取得。
- ^ Drepper, Ulrich (2000 年 6 月 26 日). 「RMS がまたやらかした」. sourceware.org. 2012 年 12 月 28 日のオリジナルからアーカイブ。2015年11 月 20 日閲覧。
数週間前、RMS は私に対する次の攻撃を開始しました (1 通のメール、続いて間接的な影響力行使の試み、そして本日の別のメール)。要点は、私が「GNU ポリシー」に従っていないので、私が参加できる運営委員会に交代させる必要があると彼が不満を述べていることです。彼が委員会の他のメンバーとして 2 人を推薦したので、皆さんのうちの何人か (特に Roland と Andreas S.) はおそらくこのことを知っているでしょう。さらに、Mark Brown もリストに載っていました (IBM にこの名前の人物がいて、このグループに当てはまると思いますが、本当に彼かどうかはわかりません)。いずれにせよ、私はこれを完全に拒否します。まったく役に立たず、むしろその逆です。まず、私は自分が違反している重要なポリシーを認識していません。唯一の理由は、私が RMS からの命令に従っていないことであり、その命令には明らかに政治的な意図がある (もちろん冒涜行為である) ことと、Winblowz のことを気にしていない (後者がまったく関係ないとしても) ことである。これらはいずれも決して変わらないだろう。
- ^ Drepper, Ulrich (2001 年 8 月 15 日). 「glibc 2.2.4」. sourceware.com. 2016 年 4 月 9 日時点のオリジナルからのアーカイブ。2015年11 月 29 日閲覧。
さて、あまり良くない話です。最近、Stallman は、glibc 開発の敵対的買収とでも言うべきことを試みました。彼は、私の背後で陰謀を企て、他の主要開発者に支配権を握るよう説得し、最終的に自分が支配権を握り、自分の好きなように指示を出そうとしました。この試みは失敗しましたが、彼はあちこちの人々に圧力をかけ続け、状況は実に醜いものになりました。最終的に、私はいわゆる「運営委員会」(SC) の設立に同意しました。
- ^ rms-accused-of-attempting-glibc-hostile-takeover 2001年8月19日、slashdot .comのWayback Machineで2020年8月1日にアーカイブ
- ^ “GNU C ライブラリ運営委員会が解散 – H Open: ニュースと特集”. H-Online . 2023年3月21日時点のオリジナルよりアーカイブ。2023年3月16日閲覧。
- ^ McGrath, Roland (2012年3月26日). 「glibc 運営委員会解散」 Sourceware.org. 2019年9月26日時点のオリジナルよりアーカイブ。2012年6月13日閲覧。
- ^ Myers, Joseph S. (2012年3月26日). 「GNU C ライブラリの開発と保守」. Sourceware.org. 2019年9月26日時点のオリジナルよりアーカイブ。2012年6月13日閲覧。
- ^ 「GNU C ライブラリマシンのメンテナー」。2016年4月18日時点のオリジナルよりアーカイブ。 2015年10月8日閲覧。
- ^ Bartley, David; Spang, Michael. 「GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)」。2019年11月6日時点のオリジナルよりアーカイブ。2008年12月16日閲覧。
- ^ 「Haiku Source」。GitHub。2016年5月1日時点のオリジナルよりアーカイブ。 2014年10月15日閲覧。libroot.so
はGNUプロジェクトの一部ではなく、Haikuソースコードに含まれています。
- ^ Torvalds, Linus (2002年1月9日). 「glibcメーリングリストへの投稿」。2015年10月12日時点のオリジナルよりアーカイブ。2007年7月22日閲覧。
- ^ 「OpenMoko コンポーネント」。2016 年 4 月 22 日のオリジナルからアーカイブ。2008年5 月 13 日閲覧
。glibc (uClibC ではない) を使用します...代替案はより多くのスペースを節約し、より最適化される可能性がありますが、統合で頭を悩ませる可能性が高くなります。
- ^ “Re: [Familiar] Familiar 0.8.4 の glibc はどれですか?”。2022年3月12日時点のオリジナルよりアーカイブ。2018年11月26日閲覧。
質問: Familiar 0.8.4 のビルドに使用された GLIBC のバージョンはどれですか?回答: 2.3.3
- ^ Kerrisk, Michael. 「strlcpy() の長所と短所」. LWN.net . 2023年12月9日時点のオリジナルよりアーカイブ。 2023年12月9日閲覧。
- ^ Corbet, Jonathan. 「glibc に strlcpy() を追加する」LWN.net。2023年 12 月 9 日時点のオリジナルよりアーカイブ。2023年12 月 9 日閲覧。
- ^ ab "FAQ". sourceware.org . 2023年12月9日時点のオリジナルよりアーカイブ。2023年12月9日閲覧。
外部リンク
- 公式サイト
