Loading article…
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 プロジェクトは、当初は主に Roland McGrath によって書かれ、彼は1987 年の夏に 10 代の頃にFree Software Foundation (FSF) で働いていました。 [ 11 ] [ 12 ] 1988 年 2 月、FSF は glibc がANSI Cで要求される機能をほぼ完成させたと説明しました。[ 13 ] 1992 年までに、ANSI C-1989 および POSIX.1-1990 の機能が実装され、POSIX.2 の作業が進められていました。[ 14 ] 1995 年 9 月に Ulrich Drepper が glibc に初めて貢献し、1997 年までにほとんどのコミットは彼によって行われました。Drepper は長年メンテナンス担当者を務め、2012 年までにプロジェクトへの全コミットの 63% を蓄積しました。[ 15 ]
2009年5月、glibcはGitリポジトリに移行されました。[ 15 ]
2010年に、GPLと互換性のないglibcのSun RPC実装が原因で発生したライセンス問題が解決されました。これは、Sun RPCコンポーネントをBSDライセンスで再ライセンスすることで解決されました。[ 16 ] [ 17 ]
2014年、glibcはs390でABI破損バグに見舞われた。[ 18 ]
2017年7月、glibcを始めてから30年後、ローランド・マクグラスは「名誉メンテナーを宣言し、プロジェクトへの直接的な関与から身を引きます。ここ数ヶ月、いやここ数年で、皆さんはもう私を必要としていないことが証明されました」と辞任を発表した。[ 11 ]
2018年、メンテナーのレイモンド・ニコルソンはglibcのソースコードから中絶に関するジョークを削除した。リチャード・ストールマンが元に戻すよう要求した後、アレクサンドル・オリバによって後に復元された。[ 19 ]
2021年に、フリーソフトウェア財団への著作権譲渡要件がプロジェクトから削除されました。[ 20 ]
1994 年、 Linux カーネル の開発者はglibc をフォークしました。彼らのフォークである「Linux libc」は、1998 年頃まで別々に維持されていました。著作権表示が不十分だったため、変更を GNU Libc にマージバックすることはできませんでした。[ 21 ] 1997 年 1 月に FSF が glibc 2.0 をリリースすると、カーネル開発者は glibc 2.0 の POSIX 標準への優れた準拠を理由に Linux libc を廃止しました。[ 22 ] glibc 2.0 は、国際化の改善、より詳細な翻訳、IPv6機能、64 ビットデータアクセス、マルチスレッドアプリケーション用の機能、将来のバージョンとの互換性、そしてコードの移植性の向上も備えていました。[ 23 ] Linux libc の最後の使用バージョンは、内部名 ( soname ) libc.so.5を使用していました。これに続いて、Linux 上の glibc 2.x は soname libc.so.6を使用します[ 24 ]
2009 年、Debianおよびいくつかの派生ディストリビューションは glibc からその派生版[ 26 ] eglibc に切り替えました。[ 27 ] eglibc は、 Freescale、MIPS、MontaVista、Wind Riverからなるコンソーシアムによってサポートされていました。[ 28 ]組み込み用途により適した変更が含まれており、 PowerPC e500など、glibc ではサポートされていないアーキテクチャのサポートが追加されていました。eglibc のコードはバージョン 2.20 で glibc に統合されました。[ 29 ] 2014 年以降、eglibc は廃止されています。Yocto Projectおよび Debian も、 Debian Jessieのリリース以降、glibc に戻りました。[ 30 ]
2001年から図書館の開発は委員会によって監督され、[ 31 ]ウルリッヒ・ドレッパー[ 32 ]が主要な貢献者および維持者として留任した。運営委員会の設置は公然と論争を巻き起こし、ウルリッヒ・ドレッパーはそれをリチャード・ストールマンによる失敗した敵対的買収工作だと公然と述べた。[ 33 ] [ 34 ] [ 35 ] [ 36 ]
2012 年 3 月、運営委員会は、コミュニティ主導の開発プロセスを採用するために、自らを解散し、ドレッパーを排除することを決議した。ライアン・アーノルド、マキシム・クヴィルコフ、ジョセフ・マイヤーズ、カルロス・オドネル、アレクサンドル・オリバが GNU の保守責任を負ったが、追加の意思決定権は持たなかった。[ 37 ] [ 38 ] [ 39 ]
glibc は、 Single UNIX Specification、POSIX (1c、1d、および 1j)で要求される機能、およびISO C11、ISO C99、Berkeley Unix (BSD) インターフェイス、System V インターフェイス定義(SVID)、X/Open 移植性ガイド(XPG) 第 4.2 版で要求される機能の一部を提供します。また、XSI ( X/Open System Interface ) 準拠システムに共通するすべての拡張機能と、すべての X/Open UNIX 拡張機能も提供します。
さらに、glibc はGNU の開発中に有用または必要であると判断された拡張機能も提供します。
glibc は、さまざまなカーネルとハードウェアアーキテクチャを実行するシステムで使用されます。最も一般的な用途は、 x86ハードウェアでLinux カーネルを使用するシステムですが、公式にサポートされているハードウェア[ 40 ]には、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のフォーク バージョンもあります。[ 41 ]また、 BeOSとHaikuでは（編集された形で）libroot.soという名前で使用されている。[ 42 ]
glibc は、過去にLinus Torvalds [ 43 ]や組み込み Linuxプログラマーなどから「肥大化」し、他のライブラリよりも遅いと批判されてきました。そのため、フットプリントの小さい代替 C 標準ライブラリがいくつか作成されました。しかし、多くの小型デバイス プロジェクトでは、アプリケーション サポート、標準への準拠、完全性などの理由から、より小型の代替ライブラリよりも GNU libc を使用しています。例としては、Openmoko [ 44 ]やiPaq ハンドヘルド向けのFamiliar Linux ( GPEディスプレイ ソフトウェアを使用する場合) [ 45 ]などがあります。
glibc はC11で定義されている境界チェック インターフェイスを実装しておらず、strlcpyとstrlcat [ 46 ] [ 47 ]も2023 年まで実装していませんでした。その理由は、「実際にはこれらの関数は、意図された使用法が暗黙のデータ切り捨てを促し、複雑さと非効率性を高め、宛先でのすべてのバッファオーバーランを防ぐわけではないため、問題を引き起こす可能性がある」というものでした。[ 48 ] FAQ では、境界チェック インターフェイスは ISO 標準ではオプションであり、snprintf が代替として利用可能であると指摘されています。[ 48 ]
他のエコシステム向けに書かれたプログラムをglibcインターフェースを提供するシステム上で実行できるようにする互換性レイヤー（「シム」）が存在します。これには、 AndroidのBionic用の互換性レイヤーであるlibhybrisや、 Windows APIからglibcおよびUnix系システムで利用可能なその他のネイティブAPIへの互換性レイヤーと見なせるWineなどが含まれます。
ヘッダーにLGPL-2.1-or-laterが含まれています
ヘッダーにLGPL-2.1-or-laterが含まれています。
ヘッダーにLGPL-2.0-or-laterが含まれています。
ほとんどのライブラリは完成しています。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メンテナンス: 場所の発行元が見つかりません (リンク)年に GNU C ライブラリ運営委員会が結成され、現在は Mark Brown、Paul Eggert、Andreas Jaeger、Jakub Jelinek、Roland McGrath、Andreas Schwab で構成されています。
数週間前、RMSは私に対する次の攻撃を開始しました（1通のメール、それに続く間接的な影響力行使の試み、そして今日の別のメール）。要点は、私が「GNUポリシー」に従っていないため、私が参加できる運営委員会に交代しなければならないと彼が不満を述べていることです。あなた方のうち何人か（特にRolandとAndreas S.）は、彼が委員会の他のメンバーとして2人を提案したので、おそらくこのことを知っているでしょう。さらにMark Brownもリストに載っていました（IBMにこの名前の人物を知っていますが、彼もこのグループにふさわしいと思いますが、本当に彼かどうかはわかりません）。いずれにせよ、私はこれを完全に拒否します。これは全く役に立たず、むしろ逆です。まず、私が違反している重要なポリシーは何も知りません。唯一の例外は、私が明らかに政治的な意図を持つRMSの命令に従っていないこと（もちろんこれは冒涜行為だ）、そしておそらく私がWinblowzに興味がないということ（後者がそもそも問題になるのかどうかは別として）だ。これらのことは何ら変わることはない。
さて、あまり良くないことについて。 Stallman は最近、私が glibc 開発の敵対的買収と呼ぶようなことを試みました。彼は私の知らないところで陰謀を企て、他の主要な開発者を説得して主導権を握らせ、最終的に自分が主導権を握り、好きなように指示できるようにしようとしました。この試みは失敗しましたが、彼はあらゆる場所で人々に圧力をかけ続け、事態は本当に醜いものになりました。最終的に私は、いわゆる「運営委員会」(SC) の設立に同意しました。
はGNUプロジェクトの一部ではなく、Haikuソースコードに含まれています。
(uClibC ではない) を使用します...代替案はより多くのスペースを節約し、より最適化されているかもしれませんが、統合の問題を引き起こす可能性が高くなります。
質問: Familiar 0.8.4 のビルドにはどのバージョンの GLIBC が使用されましたか
? 回答: 2.3.3