| GNU Cライブラリ | |
|---|---|
| 原作者 | ローランド・マクグラス |
| 開発者 | GNUプロジェクト、ウルリッヒ・ドレッパーによる貢献が最も大きい |
| 初回リリース | 1987年[ 1 ] (1987年) |
| 安定版リリース | 2.43 [ 2 ] |
| リポジトリ | |
| 書かれた | C |
| オペレーティング·システム | Unixライク |
| タイプ | ランタイムライブラリ |
| ライセンス | 2001: LGPL-2.1以降[ a ] 1992: LGPL-2.0以降[ b ] |
| Webサイト | www |
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など の基本的な機能が含まれています。
| バージョン | 日付 | ハイライト |
|---|---|---|
| 0.1~0.6 | 1991年10月~1992年2月 | |
| 1.0 | 1992年2月 | |
| 1.01 – 1.09.3 | 1992年3月~1994年12月 | |
| 1.90 – 1.102 | 1996年5月~1997年1月 | |
| 2.0 | 1997年1月 | |
| 2.0.1 | 1997年1月 | |
| 2.0.2 | 1997年2月 | |
| 2.0.91 | 1997年12月 | |
| 2.0.95 | 1998年7月 | |
| 2.1 | 1999年2月 | |
| 2.1.1 | 1999年3月 | |
| 2.2 | 2000年11月 | |
| 2.2.1 | 2001年1月 | |
| 2.2.2 | 2001年2月 | |
| 2.2.3 | 2001年3月 | |
| 2.2.4 | 2001年7月 | |
| 2.3 | 2002年10月 | |
| 2.3.1 | 2002年10月 | |
| 2.3.2 | 2003年2月 | |
| 2.3.3 | 2003年12月 | |
| 2.3.4 | 2004年12月 | Linux Standard Base (LSB) 3.0 の最小要件 |
| 2.3.5 | 2005年4月 | |
| 2.3.6 | 2005年11月 | |
| 2.4 | 2006年3月 | LSB 4.0の最小値、初期のinotifyサポート |
| 2.5 | 2006年9月 | inotifyの完全サポート。RHEL5のサポートは2020年11月30日に終了しました。 ( 2020-11-30 ) |
| 2.6 | 2007年5月 | |
| 2.7 | 2007年10月 | |
| 2.8 | 2008年4月 | |
| 2.9 | 2008年11月 | |
| 2.10 | 2009年5月 | LSB 5.0の最小値。初期psiginfoは2021年9月19日にWayback Machineサポートにアーカイブされています。 |
| 2.11 | 2009年10月 | SLES11 は2022 年 3 月に長期サポートが終了しました。 |
| 2.12 | 2010年5月 | |
| 2.13 | 2011年1月 | |
| 2.14 | 2011年6月 | |
| 2.15 | 2012年3月 | |
| 2.16 | 2012年6月 | x32 ABIサポート、ISO C11準拠、SystemTap |
| 2.17 | 2012年12月 | 64ビットARMサポート |
| 2.18 | 2013年8月 | C++11のサポートが強化されました。Intel TSXロック省略のサポート。Xilinx MicroBlazeおよびIBM POWER8マイクロアーキテクチャのサポート。 |
| 2.19 | 2014年2月 | malloc用のSystemTapプローブ。ppc32およびppc64向けのGNU間接関数(IFUNC)サポート。_SVID_SOURCEおよび_BSD_SOURCEに代わる新機能テストマクロ_DEFAULT_SOURCE。マニュアル内の全関数の安全性に関する暫定的なドキュメント。s390/s390xのucontextおよびjmp_bufのABI変更。 |
| 2.20 | 2014年9月 | ファイル記述ロックのサポート |
| 2.21 | 2015年2月 | 新しいセマフォ実装 |
| 2.22 | 2015年8月 | 元々 x86 で実行されていたGoogle Native Client (NaCl) をARMv7-A、Unicode 7.0 で実行できるようにサポート |
| 2.23 | 2016年2月 | ユニコード8.0 |
| 2.24 | 2016年8月 | 一部の廃止予定の機能は削除されました |
| 2.25 | 2017年2月 | 関数getentropyとgetrandomヘッダー<sys/random.h>ファイルが追加されました。 |
| 2.26 | 2017年8月 | パフォーマンスの向上(mallocのスレッドごとのキャッシュ)、Unicode 10のサポート |
| 2.27 | 2018年2月 | パフォーマンスの最適化。RISC -V のサポート。 |
| 2.28 | 2018年8月 | statx、、renameat2ユニコード 11.0.0 |
| 2.29 | 2019年2月 |
|
| 2.30 | 2019年8月 | Unicode 12.1.0では、動的リンカーが--preload共有オブジェクトをプリロードするための引数を受け入れるようになり、gettidLinuxに関数が追加され、民国(中華民国)暦のサポート、ja_JPロケールに新しい日本の元号が追加され、メモリ割り当て関数はオブジェクトの合計サイズがより大きい場合に失敗するPTRDIFF_MAX;CVE - 2019-7309およびCVE- 2019-9169が修正された[ 8 ] |
| 2.31 | 2020年2月 | C23標準の初期サポート |
| 2.32 | 2020年8月 | Unicode 13.0、GCC 10でのより良い警告のための「access」属性、すなわち「バッファオーバーフローやその他の境界外アクセスの検出を助ける」[ 9 ] |
| 2.33 | 2021年2月 | HWCAPS |
| 2.34 | 2021年8月 | libpthread、libdl、libutil、libanl は libc に統合されました。 |
| 2.35 | 2022年2月 | Unicode 14.0、C.UTF-8ロケール、再起動可能なシーケンス。Intel MPXのサポートを削除しました。 |
| 2.36 | 2022年8月 | |
| 2.37 | 2023年2月 | |
| 2.38 | 2023年8月 | strlcpy および strlcat 関数が追加されました。ARM64 の libmvec サポート。 |
| 2.39 | 2024年1月 | ISO C2Xからstdbit.hヘッダーが追加されました。x86_64上のシャドウスタックのサポート、新しいセキュリティ機能、libcryptの削除が追加されました。 |
| 2.40 | 2024年7月 | ISO C23標準の部分的なサポート、 setuidプログラムのテスト用の新しい調整可能パラメータ、64 ビット ARM ベクトル サポートの改善。 |
| 2.41 | 2025年1月 | sinpi、cospi、Tanpi関数を追加します。 |
| 2.42 | 2025年7月 | 新しい数学関数、termios.h インターフェイスでの任意のボー レートのサポート、SFrame ベースのスタック トレース。 |



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が含まれます。
ヘッダーにLGPL-2.1以降
閲覧。ヘッダーにLGPL-2.1以降が記載されている。
ヘッダーにLGPL-2.0以降が記載されている。
ライブラリの大部分は完成しています。Roland McGrath [...] はほぼ完全なANSI Cライブラリ関数セットを所有しています。この春中に完成することを期待しています。
現在、ANSI C-1989およびPOSIX.1-1990のすべての関数が含まれており、POSIX.2およびUnix関数(BSDおよびSystem V)の作業が進行中です。
プロジェクトのgitリポジトリ(1995年以降の変更を含む)にある約19,000件のコミットのうち、12,000件以上はUlrichによるものである。
。GNU LIBCとLinux LIBCの分裂 -- Linuxが安定するまで何年も続いたが、その後フォークは1つのプロジェクトに再統合された。
{{cite book}}: CS1 メンテナンス: 場所の発行元が見つかりません (リンク){{cite book}}: CS1 メンテナンス: 場所の発行元が見つかりません (リンク)2001年にGNU Cライブラリ運営委員会が結成され、現在はMark Brown、Paul Eggert、Andreas Jaeger、Jakub Jelinek、Roland McGrath、Andreas Schwabで構成されています。
数週間前、RMSは私への新たな攻撃を開始しました(1通のメール、その後間接的な影響力行使の試み、そして本日別のメール)。要点は、私が「GNUポリシー」に従っていないため、私が参加できる運営委員会を設立して交代させるべきだというものです。RolandとAndreas S.は、彼が委員会の他のメンバーとして両者を提案したので、おそらく皆さんのうち何人か(特にRolandとAndreas S.)はこれをご存知でしょう。さらに、Mark Brownもリストに載っていました(IBMにこの名前の人物がいて、このグループに当てはまると思いますが、本当に彼かどうかは分かりません)。いずれにせよ、私はこれを完全に拒否します。これは全く役に立たず、むしろその逆です。まず、私は自分が違反している重要なポリシーを認識していません。唯一の理由は、RMSの命令には明らかに政治的な意図がある(もちろん冒涜ですが)ので従わないということと、Winblowzのことなど気にしていない(後者がそもそも問題になるかどうかは別として)ということだけです。これらは決して変わりません。
さて、あまり良くない話に移りましょう。ストールマンは最近、glibc開発の敵対的買収とでも言うべきことを試みました。彼は私の背後で陰謀を企み、他の主要開発者を説得して支配権を握らせようとしました。最終的には自分が主導権を握り、自分の思い通りに物事を進めようとしたのです。この試みは失敗に終わりましたが、彼はあらゆる場所に圧力をかけ続け、事態は悪化の一途を辿りました。最終的に私は、いわゆる「運営委員会」(SC)の設立に同意しました。
はGNUプロジェクトの一部ではなく、Haikuソースコードに含まれています。
(uClibCではない)を使用します。代替案はより多くのスペースを節約し、より最適化される可能性がありますが、統合に頭を悩ませる可能性が高くなります。
質問:Familiar 0.8.4 のビルドに使用された GLIBC のバージョンは?回答:2.3.3