ทำไม glibc จึงถูกดูแลแยกจาก GCC

GCC เป็นคอมไพเลอร์ C Glibc เป็นไลบรารี C อย่างไรก็ตามมันเป็นความจำเป็นอย่างยิ่งสำหรับคอมไพเลอร์และไลบรารีมาตรฐานที่รวมเข้าด้วยกันเป็นการนำ C ไปใช้หรือไม่?

ยกตัวอย่างเช่นห้องสมุด C มี ABI และคอมไพเลอร์ที่เฉพาะเจาะจงสิ่งที่ชอบ<limits.h>, <stdint.h>เป็นต้นซึ่งแตกต่างระหว่างคอมไพเลอร์และ API และรายละเอียดเช่น "วิธีการเรียกใช้ฟังก์ชั่นหลัก" นั้นยังขึ้นอยู่กับคอมไพเลอร์libc.soด้วย ตัวอย่างเช่นถ้าฉันเปลี่ยนคอมไพเลอร์ให้ทำงานกับ ABI อื่นเช่นใช้intกับ 8 ไบต์ไลบรารี C จะไม่ทำงานอีกต่อไปเพราะสิ่งที่อยู่ใน<limits.h>นั้นจะผิด

c gcc

— Michael Tsang
แหล่งที่มา

คำตอบ:

หนึ่งในเหตุผลก็คือว่าGCCสามารถสร้างและใช้กับ (เช่นระบบ Unix เป็นกรรมสิทธิ์เช่น MacOSX โซลาริส HPUX หรือ FreeBSD) ระบบของตัวเองที่มีมาตรฐานห้องสมุด C

แม้ในลินุกซ์, คุณสามารถมีไลบรารีมาตรฐาน C ซึ่งไม่ได้เป็นGNU Glibc โดยเฉพาะคุณสามารถสร้าง GCC (หรือใช้) บนระบบ Linux ด้วยmusl-libcหรือBionic (ระบบ Android) หรือกับdietlibcเป็นต้นและระบบ Linux อาจมี GNU Glibc และใช้คอมไพเลอร์ C อื่น ๆ (เช่นClangหรือ TinyCC)

นอกจากนี้ไลบรารี C ขึ้นอยู่กับเคอร์เนลของ Linux เป็นอย่างมาก เคอร์เนลเวอร์ชันเก่าบางรุ่นอาจต้องการชนิด (หรือรุ่น) บางอย่างlibc

และ GCC เป็น buildable เป็นcompiler ข้าม

และรายละเอียดเช่น "วิธีการเรียกใช้mainฟังก์ชัน" ยังขึ้นอยู่กับคอมไพเลอร์ด้วย แต่ในความเป็นจริงรายละเอียดเหล่านั้นถูกจัดทำโดยlibc.soระบบ Linux

นั่นไม่ถูกต้องอย่างแน่นอน mainฟังก์ชั่นที่เรียกว่า (ในสภาพแวดล้อมที่เป็นเจ้าภาพ) โดยcrt0สิ่งบางอย่างที่ให้บริการโดย GCC (เช่น/usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.oบนของ Debian / ซิด / x86-64 อยู่ห่างจากlibgcc-6-devแพคเกจ) อ่านเกี่ยวกับlibgcc

ที่จริงมีบางความสัมพันธ์ครึ่งซ่อนระหว่างlibcและ GCC เช่นเพราะหลายlibcส่วนหัวมี (ขยะ) โดยใช้ gcc บางbuiltinsหรือแอตทริบิวต์ของฟังก์ชั่น

^{(ด้วยเหตุนี้นักพัฒนา GCC และนักพัฒนา GNU libc จะต้องโต้ตอบกัน)}

.... ถ้าฉันเปลี่ยนคอมไพเลอร์ให้ทำงานกับ ABI อื่น ...

คุณจะต้อง ... /configureคอมไพเลอร์ GCC และสร้างใหม่และคุณอาจต้องแก้ไขคอมไพเลอร์ GCC (เพื่ออธิบาย ABI ของคุณและการเรียกประชุม ) x32 ABIเป็นตัวอย่างที่ดี

ที่ล่าสุดร่วมสมทบบางส่วนหรือดูแลของ GCC (รวมทั้งผม) ได้ลงนามมอบหมายลิขสิทธิ์ซึ่งครอบคลุม GCC แต่ไม่ glibcGNU

^{(เกี่ยวกับสิทธิ์ใช้งาน GCC โปรดอ่านข้อยกเว้นของไลบรารีรันไทม์ GCCอย่างระมัดระวัง)}

โปรดสังเกตว่าส่วนหัวมาตรฐานบางอย่างเช่น<limits.h>หรือ<stdint.h>จัดหาโดย GCC อื่น ๆ เช่น<stdlib.h>"คงที่" ในระหว่างการสร้าง GCC: ขั้นตอนการสร้างคอมไพเลอร์นำพวกเขาจากการใช้ Libc และแก้ไขพวกเขา ยังคงหัวมาตรฐานอื่น ๆ (อาจ<stdio.h>และหัวต่อภายในมันจะรวมถึง) libcถูกนำมาจาก อ่านเพิ่มเติมเกี่ยวกับGCC FIXINCLUDESและส่วนหัวของแฟ้มคงที่

^{(สิ่งที่รวมอยู่คือสิ่งที่ฉัน (Basile) ยังไม่เข้าใจดี)}

คุณสามารถรวบรวมgcc -v -Hเพื่อทำความเข้าใจได้อย่างแม่นยำมากขึ้นว่าโปรแกรมจริงใดที่ทำงานอยู่ (เนื่องจากgccเป็นไดร์เวอร์, รันcc1คอมไพเลอร์, ld& collect2linkers, แอสasเซมเบลอร์, ฯลฯ ... ) และส่วนหัวใดรวมอยู่ด้วย โดยนัยรวมถึงไลบรารีมาตรฐาน C และcrt0 ) อ่านเพิ่มเติมเกี่ยวกับ GCC ตัวเลือก

BTW คุณสามารถใช้ไลบรารีมาตรฐาน C ที่แตกต่างจาก GCC ที่คุณคาดหวังหรือสร้างขึ้นสำหรับ (เช่นmusl-libcหรือdietlibcบางส่วน) โดยข้ามอาร์กิวเมนต์พิเศษที่เหมาะสมเพื่อgcc...

— Basile Starynkevitch
แหล่งที่มา

คำตอบที่ถูกต้องแม้ว่าจะไม่ใช่การออกแบบที่ถูกต้องก็ตาม นี่คือสาเหตุที่ MSVC ++ สามารถรวบรวมรหัส C ++ 11 / C ++ 14 สำหรับระบบปฏิบัติการ pre-2011/2014 แต่ GCC มักจะไม่สามารถทำได้

— MSalters

คุณหมายถึงอะไรโดย "ไม่ใช่การออกแบบที่ถูกต้อง"? และฉันไม่แน่ใจว่า GCC ไม่สามารถรวบรวมรหัส C ++ 14 สำหรับระบบปฏิบัติการเก่า (อย่างไรก็ตามคุณอาจต้องรวบรวม GCC ล่าสุดในระบบปฏิบัติการรุ่นเก่า)

— Basile Starynkevitch

ตามมาตรฐาน ISO C, C Standard Library เป็นส่วนหนึ่งของคอมไพเลอร์ การถือครองเดียวกันสำหรับไลบรารี C ++ ตอนนี้ปัญหาคือแอปพลิเคชันที่สร้างด้วย GCC เวอร์ชันใหม่จะมีการพึ่งพา glibc ของระบบปฏิบัติการที่สร้างขึ้นซึ่งอาจใหม่กว่า glibc บนระบบเป้าหมาย ทางออกที่ดีกว่าน่าจะเป็นที่พึ่งพาบนgcclibcไลบรารี่ระบบปฏิบัติการ แต่เป็นเวอร์ชั่นที่เป็นส่วนหนึ่งของ GCC ไม่ใช่ระบบปฏิบัติการ

— MSalters

คุณแน่ใจหรือว่ามาตรฐาน C11 หรือ C ++ 14 พูดถึงคำว่า "คอมไพเลอร์"? AFAIU พวกเขาพูดถึง "การนำไปปฏิบัติ" (ซึ่งอาจไม่ใช่ซอฟต์แวร์)

— Basile Starynkevitch

ส่วนหัวบางอย่างเช่น<stdint.h>หรือ<limits.h>จัดหาโดย GCC ส่วนหัวอื่น ๆ เช่น<stdlib.h>ที่นำมาจากห้องสมุด C และ "แก้ไข" ในระหว่างการสร้าง GCC

— Basile Starynkevitch

-5

คำตอบสั้น ๆ คือถ้าทั้งสองถูกรวมเข้าด้วยกัน glibc จะได้รับอนุญาตภายใต้ GPL * และดังนั้นจึงไม่เหมาะสมอย่างสมบูรณ์สำหรับโครงการที่เป็นกรรมสิทธิ์ ในขณะที่โครงการ FSF และ GNU ไม่มีความรักในซอฟต์แวร์ที่เป็นกรรมสิทธิ์ glibc ได้รับใบอนุญาต LGPL เป็นตัวเลือกเชิงกลยุทธ์เพื่อการยอมรับ GCC และระบบนิเวศซอฟต์แวร์ฟรี GCC ได้รับสิทธิ์ใช้งานจริงภายใต้ GPL โดยมีข้อยกเว้นเฉพาะการเชื่อมโยงขณะใช้งานจริงเนื่องจากสถานการณ์ค่อนข้างเป็นโคลน glibc ได้รับสิทธิ์การใช้งานต่อ LGPL เพื่ออนุญาตให้ใช้งานไลบรารีที่ใช้ร่วมกันอย่างสมเหตุสมผล

https://www.gnu.org/licenses/gcc-exception-faq.html

นอกจากนี้ glibc ยังมี shims และส่วนประกอบอื่น ๆ ทุกชนิดเพื่อปรับให้เข้ากับระบบปฏิบัติการที่แตกต่างกันและแจกจ่ายว่าเป็นแพ็คเกจเดียวกันกับ gcc จะทำให้สิ่งต่าง ๆ ยุ่งเหยิง

* อีกทางเลือกหนึ่ง GCC สามารถได้รับใบอนุญาตภายใต้ GPL อื่น ๆ แม้ว่าความคิดของ FSF เกี่ยวกับเรื่องนี้จะเป็นไปตามแนวของ "เหนือร่างกายของฉัน"

— whatsisname
แหล่งที่มา

ขออภัยคำตอบนี้ผิด IMHO "การรวมเข้าด้วยกัน" ไม่ได้แปลว่าการทำงานที่ได้มาจาก GCC ในแง่ที่อธิบายไว้ใน GPL ตัวอย่างเช่นแพคเกจซอฟต์แวร์จำนวนมากที่ใช้สัญญาอนุญาตโอเพนซอร์ซที่ต่างกันนั้น "รวมกัน" ในลีนุกซ์ดิสทริบิวชั่นแต่ละชุดอย่างไรก็ตามแพ็คเกจเหล่านี้ไม่ได้ละเมิด GPL

— Doc Brown

ทำไมการรวม gcc และ glibc เข้าด้วยกันบังคับให้ glibc อยู่ภายใต้ GPL ความเข้าใจของฉันคือการรวมกลุ่มไม่ใช่ "งานที่รวมกัน" ดังนั้น GPL จึงไม่ข้ามพรมแดน แก้ไข: สิ่งที่ Doc Brown กล่าวว่า :-)

— Philip Kendall