GNU Cライブラリ（通称glibc）は、 C標準ライブラリのGNUプロジェクトによる実装です。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など の基本的な機能が含まれています。

歴史

2007年、glibcの主要著者であるウルリッヒ・ドレッパー
GNU C ライブラリは、Linux カーネルのシステム コールをラップするものです。
LinuxカーネルとGNU CライブラリはLinux APIを構成します。コンパイル後、バイナリはABIを提供します。

glibcプロジェクトは、1987年の夏、当時10代だったローランド・マグラスが主にフリーソフトウェア財団（FSF）で働いていたことで始まりました。 [ 10 ] [ 11 ] 1988年2月、FSFはglibcがANSI Cに必要な機能をほぼ完成させたと述べました。[ 12 ] 1992年までに、ANSI C-1989とPOSIX.1-1990の機能が実装され、POSIX.2の作業が進行中でした。[ 13 ] 1995年9月、ウルリッヒ・ドレッパーがglibcに初めて貢献し、1997年までにほとんどのコミットは彼によって行われました。ドレッパーは長年メンテナを務め、2012年までにプロジェクトへのコミットの63%を占めました。[ 14 ]

2009年5月にglibcはGitリポジトリに移行されました。[ 14 ]

2010年には、 glibcのSun RPC実装がGPL非互換であったことに起因するライセンス問題が解決されました。この問題は、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 Specification、POSIX (1c、1d、および 1j)で必要な機能と、 ISO C11、ISO C99、Berkeley Unix (BSD) インターフェース、System V Interface Definition (SVID)、およびX/Open Portability Guide (XPG)、Issue 4.2 で必要な機能の一部を提供します。さらに、XSI ( X/Open System Interface ) 準拠システムに共通するすべての拡張機能と、すべての 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が含まれます。

参照

注記

  1. ^ LGPL-2.1以降、2001年7月6日以降、バージョン2.2.4。 [ 3 ] [ 4 ]
  2. ^ LGPL-2.0以降（1992年から2001年7月5日）。バージョン1.04?から2.2.3。 [ 5 ] [ 6 ]

参考文献

  1. ^ Corbet, Jonathan (2012年3月28日). 「GNU libcの転換点」 . LWN.net. 2016年4月23日時点のオリジナルよりアーカイブ。2012年4月5日閲覧。
  2. ^ Andreas K. Hüttel (2026年1月24日). 「GNU Cライブラリバージョン2.43が利用可能になりました」 . 2026年1月24日閲覧。
  3. ^ a b "sourceware.org Git – glibc.git/blob – Makefile" . sourceware.org . 2021年6月10日時点のオリジナルよりアーカイブ。2021年6月10日閲覧。ヘッダーにLGPL-2.1以降が含まれています。
  4. ^ "sourceware.org Git – glibc.git/commit – LGPL v.2.1へのアップデート" . sourceware.org . 2001年7月6日. 2021年6月10日時点のオリジナルよりアーカイブ。2021年6月10日閲覧。ヘッダーにLGPL-2.1以降が記載されている。
  5. ^ “glibc-1.04.tar.Z” . 1992年9月4日. 2021年12月22日時点のオリジナルよりアーカイブ。 2021年12月22日閲覧。
  6. ^ "sourceware.org Git – glibc.git/commit – 初期インポート: Makefile" . sourceware.org . 1995年2月18日. 2021年6月10日時点のオリジナルよりアーカイブ。2021年6月10日閲覧。ヘッダーにLGPL-2.0以降が記載されている。
  7. ^ “sourceware.org Git – glibc.git/blob – NEWS” . 2022年3月21日時点のオリジナルよりアーカイブ。2019年4月26日閲覧。
  8. ^ “sourceware.org Git – glibc.git/blob – NEWS” . 2019年9月26日時点のオリジナルよりアーカイブ。2019年4月26日閲覧。
  9. ^ “GNU C ライブラリ バージョン 2.32 が利用可能になりました” . sourceware.org . 2020年9月28日時点のオリジナルよりアーカイブ。2020年8月13日閲覧。
  10. ^ a b “Roland McGrath bows out as glibc maintainer [LWN.net]” . lwn.net . 2017年7月7日. 2020年8月1日時点のオリジナルよりアーカイブ。 2017年7月8日閲覧。
  11. ^ Chirgwin, Richard (2017年7月10日). 「Roland McGrath、30年間のglibcメンテナー職を退任」 . The Register . Situation Publishing. 2024年3月7日時点のオリジナルよりアーカイブ。 2024年6月1日閲覧。
  12. ^ 「GNU's Bulletin, vol. 1 no. 4, February, 1988」。2016年4月16日時点のオリジナルよりアーカイブ。2014年4月16日閲覧。ライブラリの大部分は完成しています。Roland McGrath [...] はほぼ完全なANSI Cライブラリ関数セットを所有しています。この春中に完成することを期待しています。
  13. ^ 「GNUの速報 第1巻 第12号」。2016年3月11日時点のオリジナルよりアーカイブ。2014年4月16日閲覧。現在、ANSI C-1989およびPOSIX.1-1990のすべての関数が含まれており、POSIX.2およびUnix関数（BSDおよびSystem V）の作業が進行中です。
  14. ^ a b Corbet, Jonathan (2012年3月28日). 「GNU libcの転換点」 . LWN.net. 2016年4月23日時点のオリジナルよりアーカイブ。 2012年4月5日閲覧。プロジェクトのgitリポジトリ（1995年以降の変更を含む）にある約19,000件のコミットのうち、12,000件以上はUlrichによるものである。
  15. ^ 「Glibcがついにフリーソフトウェアに – The H Open: ニュースと特集」H-online。2022年3月21日時点のオリジナルよりアーカイブ。 2021年9月19日閲覧。
  16. ^ Phipps, Simon (2010年9月2日). 「Gnu/Linux: ついに、真のフリーソフトウェアに」 . InfoWorld . 2021年10月28日時点のオリジナルよりアーカイブ。 2021年9月19日閲覧。
  17. ^ Corbet, Jonathan. 「glibc s390 ABIの不具合 [LWN.net]」 . LWN.net . 2022年3月17日時点のオリジナルよりアーカイブ。 2022年3月17日閲覧。
  18. ^ Claburn, Thomas. 「Glibcの『中絶ジョーク』のdiff論争でリチャード・ストールマンが激怒」 The Register . 2023年1月17日時点のオリジナルよりアーカイブ。 2023年1月17日閲覧。
  19. ^ Halfacree, Gareth. 「オープンソースプロジェクトのglibcとgnulibがフリーソフトウェア財団との著作権関係を断つ可能性」 The Register . 2023年1月17日時点のオリジナルよりアーカイブ。 2023年1月17日閲覧。
  20. ^ 「glibcとLinux libcの歴史」 .フリーソフトウェアマガジン. 2021年9月26日時点のオリジナルよりアーカイブ。2021年5月10日閲覧。
  21. ^ 「フォーク：あなたにも起こり得る」 2000年10月24日。2009年9月15日時点のオリジナルよりアーカイブ。GNU LIBCとLinux LIBCの分裂 -- Linuxが安定するまで何年も続いたが、その後フォークは1つのプロジェクトに再統合された。
  22. ^ Lee, Elliot (1998年7月9日). 「glibc 2.xとレガシーシステムライブラリの技術比較」 . 2004年4月11日時点のオリジナルよりアーカイブ。
  23. ^ Moen, Rick (2021年5月20日) [1999年11月14日]. 「フォークへの恐怖に関するエッセイ」 . linuxmafia.com . 6. glibc --> Linux libc --> glibc. 2023年11月27日時点のオリジナルよりアーカイブ。
  24. ^ “EGLIBC: FAQ” . eglibc.org . 2012年3月17日時点のオリジナルよりアーカイブ。2021年9月16日閲覧。
  25. ^ eglibcの開発者は、eglibcはglibcのフォークではなく、上流のglibcプロジェクトからのパッチを受け入れる変種であることを強調した。 [ 24 ]
  26. ^ Vaduva, Alexandru (2016). Linux: 組み込み開発：Linuxのパワーを活用して魅力的で強力な組み込みLinuxプロジェクトを開発する：3つのモジュールからなるコース. Alex Gonzalez, Chris Simmonds. 英国バーミンガム: Packt Publishing. p. 24. ISBN 978-1-78712-445-5. OCLC  960471438 .
  27. ^ジュリアス、スティベルト (2009 年 5 月 6 日)。「Debian wechselt zur Eglibc」。ゴーレムで。2021年9月16日のオリジナルからアーカイブ。2021 年9 月 16 日に取得。
  28. ^ Simmonds, Chris (2017). 『組み込みLinuxプログラミングをマスターする：組み込みLinuxの潜在能力を最大限に引き出す（第2版）』バーミンガム、イギリス. p. 26. ISBN 978-1-78728-885-0. OCLC  995052708 .{{cite book}}: CS1 メンテナンス: 場所の発行元が見つかりません (リンク)
  29. ^ Vaduva, Alexandru (2015). 『Yoctoプロジェクトを使った組み込みLinuxの学習：Yoctoプロジェクトのコンポーネントで強力な組み込みLinuxシステムを開発する』 イギリス、バーミンガム. p. 29. ISBN 978-1-78439-519-3. OCLC  914797028 .{{cite book}}: CS1 メンテナンス: 場所の発行元が見つかりません (リンク)
  30. ^ "glibcホームページ"。2016年4月22日時点のオリジナルよりアーカイブ。2014年4月16日閲覧。2001年にGNU Cライブラリ運営委員会が結成され、現在はMark Brown、Paul Eggert、Andreas Jaeger、Jakub Jelinek、Roland McGrath、Andreas Schwabで構成されています。
  31. ^ 「Ulrich Drepper」 LinkedIn。2014年9月10日時点のオリジナルよりアーカイブ。 2012年6月13日閲覧。
  32. ^オンライン、ヘイセ (2001 年 8 月 19 日)。「オープンソース - Entwickler kritisiert Stallman」。heise オンライン(ドイツ語)。2021年9月16日のオリジナルからアーカイブ。2021 年9 月 16 日に取得。
  33. ^ Drepper, Ulrich (2000年6月26日). 「RMSがまたやって来た」 . sourceware.org.オリジナルから2012年12月28日アーカイブ. 2015年11月20日閲覧。数週間前、RMSは私への新たな攻撃を開始しました（1通のメール、その後間接的な影響力行使の試み、そして本日別のメール）。要点は、私が「GNUポリシー」に従っていないため、私が参加できる運営委員会を設立して交代させるべきだというものです。RolandとAndreas S.は、彼が委員会の他のメンバーとして両者を提案したので、おそらく皆さんのうち何人か（特にRolandとAndreas S.）はこれをご存知でしょう。さらに、Mark Brownもリストに載っていました（IBMにこの名前の人物がいて、このグループに当てはまると思いますが、本当に彼かどうかは分かりません）。いずれにせよ、私はこれを完全に拒否します。これは全く役に立たず、むしろその逆です。まず、私は自分が違反している重要なポリシーを認識していません。唯一の理由は、RMSの命令には明らかに政治的な意図がある（もちろん冒涜ですが）ので従わないということと、Winblowzのことなど気にしていない（後者がそもそも問題になるかどうかは別として）ということだけです。これらは決して変わりません。
  34. ^ Drepper, Ulrich (2001年8月15日). "glibc 2.2.4" . sourceware.com.オリジナルから2016年4月9日アーカイブ。2015年11月29日閲覧。さて、あまり良くない話に移りましょう。ストールマンは最近、glibc開発の敵対的買収とでも言うべきことを試みました。彼は私の背後で陰謀を企み、他の主要開発者を説得して支配権を握らせようとしました。最終的には自分が主導権を握り、自分の思い通りに物事を進めようとしたのです。この試みは失敗に終わりましたが、彼はあらゆる場所に圧力をかけ続け、事態は悪化の一途を辿りました。最終的に私は、いわゆる「運営委員会」（SC）の設立に同意しました。
  35. ^ rms-accused-of-attempting-glibc-hostile-takeover 2001年8月19日、 slashdot.comのWayback Machineで2020年8月1日にアーカイブ
  36. ^ “GNU Cライブラリ運営委員会が解散 – H Open: ニュースと特集” . H-Online . 2023年3月21日時点のオリジナルよりアーカイブ。 2023年3月16日閲覧。
  37. ^ McGrath, Roland (2012年3月26日). 「glibc 運営委員会解散」 . Sourceware.org. 2019年9月26日時点のオリジナルよりアーカイブ。2012年6月13日閲覧。
  38. ^ Myers, Joseph S. (2012年3月26日). 「GNU C ライブラリの開発と保守」 . Sourceware.org. 2019年9月26日時点のオリジナルよりアーカイブ。2012年6月13日閲覧。
  39. ^ 「GNU Cライブラリマシンのメンテナー」。2016年4月18日時点のオリジナルよりアーカイブ。2015年10月8日閲覧。
  40. ^ Bartley, David; Spang, Michael. 「GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)」 。 2019年11月6日時点のオリジナルよりアーカイブ。 2008年12月16日閲覧。
  41. ^ 「Haikuソース」。GitHub 。 2016年5月1日時点のオリジナルからのアーカイブ。2014年10月15日閲覧。libroot.soはGNUプロジェクトの一部ではなく、Haikuソースコードに含まれています。
  42. ^ Torvalds, Linus (2002年1月9日). 「glibcメーリングリストへの投稿」 . 2015年10月12日時点のオリジナルよりアーカイブ。2007年7月22日閲覧。
  43. ^ 「OpenMokoコンポーネント」。2016年4月22日時点のオリジナルからアーカイブ。2008年5月13日閲覧。glibc （uClibCではない）を使用します。代替案はより多くのスペースを節約し、より最適化される可能性がありますが、統合に頭を悩ませる可能性が高くなります。
  44. ^ “Re: [Familiar] Familiar 0.8.4 の glibc はどれですか？”オリジナルより2022年3月12日アーカイブ。 2018年11月26日閲覧。質問：Familiar 0.8.4 のビルドに使用された GLIBC のバージョンは？回答：2.3.3
  45. ^ Kerrisk, Michael. 「strlcpy() の長所と短所」 . LWN.net . 2023年12月9日時点のオリジナルよりアーカイブ。 2023年12月9日閲覧。
  46. ^ Corbet, Jonathan. 「glibcにstrlcpy()を追加する」 LWN.net . 2023年12月9日時点のオリジナルよりアーカイブ。 2023年12月9日閲覧。
  47. ^ a b「FAQ」 . sourceware.org . 2023年12月9日時点のオリジナルよりアーカイブ。 2023年12月9日閲覧。
ウィキメディア コモンズには、 GNU C ライブラリに関連するメディアがあります。