เอกสาร<ก่อนหน้านี้ | Contents | ถัดไป>
5.2. หมายเหตุทางเทคนิคของ Toolchain
ส่วนนี้อธิบายรายละเอียดเหตุผลและทางเทคนิคเบื้องหลังวิธีการสร้างโดยรวม ไม่จำเป็นต้องเข้าใจทุกอย่างในส่วนนี้ทันที ข้อมูลส่วนใหญ่จะชัดเจนขึ้นหลังจากดำเนินการสร้างจริง ส่วนนี้สามารถอ้างอิงได้ตลอดเวลาในระหว่างกระบวนการ
เป้าหมายโดยรวมของบทที่ 5 คือการสร้างพื้นที่ชั่วคราวที่มีชุดเครื่องมือที่เป็นที่รู้จักซึ่งสามารถแยกออกจากระบบโฮสต์ได้ โดยใช้ โครตคำสั่งในบทที่เหลือจะอยู่ภายในสภาพแวดล้อมนั้น เพื่อสร้างความมั่นใจว่าระบบ LFS เป้าหมายจะสมบูรณ์และปราศจากปัญหา กระบวนการสร้างได้รับการออกแบบมาเพื่อลดความเสี่ยงสำหรับผู้อ่านใหม่ ๆ และเพื่อให้มีคุณค่าทางการศึกษามากที่สุดในเวลาเดียวกัน
หมายเหตุ
ก่อนดำเนินการต่อ ให้นึกถึงชื่อของแพลตฟอร์มการทำงาน ซึ่งมักเรียกกันว่าแฝดสามเป้าหมาย วิธีง่ายๆ ในการระบุชื่อแฝดเป้าหมายคือการเรียกใช้ config.เดา สคริปต์ที่มาพร้อมกับซอร์สของแพ็คเกจมากมาย แกะแหล่ง Binutils และเรียกใช้สคริปต์: ./config.guess และสังเกตผลลัพธ์ ตัวอย่างเช่น สำหรับโปรเซสเซอร์ Intel แบบ 32 บิต ผลลัพธ์จะเป็น i686-pc-ลินุกซ์-gnu. ในระบบ 64 บิตจะเป็น x86_64-pc-ลินุกซ์-gnu.
นอกจากนี้ พึงทราบชื่อของตัวเชื่อมโยงแบบไดนามิกของแพลตฟอร์ม ซึ่งมักเรียกกันว่าตัวโหลดไดนามิก (เพื่อไม่ให้สับสนกับตัวเชื่อมโยงมาตรฐาน ld ซึ่งเป็นส่วนหนึ่งของ Binutils) ตัวเชื่อมโยงแบบไดนามิกที่จัดเตรียมโดย Glibc จะค้นหาและโหลดไลบรารีที่แบ่งใช้ซึ่งโปรแกรมต้องการ เตรียมโปรแกรมให้ทำงาน จากนั้นจึงเรียกใช้ ชื่อของตัวเชื่อมโยงแบบไดนามิกสำหรับเครื่อง Intel รุ่น 32 บิตจะเป็น ld-linux.so.2 (ld-linux-x86-64.so.2 สำหรับระบบ 64 บิต) วิธีที่แน่นอนในการกำหนดชื่อของตัวเชื่อมโยงแบบไดนามิกคือการตรวจสอบไบนารีแบบสุ่มจากระบบโฮสต์โดยการเรียกใช้: readelf -l | ล่าม grep และสังเกตผลลัพธ์ ข้อมูลอ้างอิงที่เชื่อถือได้ซึ่งครอบคลุมทุกแพลตฟอร์มอยู่ใน shlib-รุ่น ไฟล์ในรูทของแผนผังต้นทาง Glibc
หมายเหตุ
ก่อนดำเนินการต่อ ให้นึกถึงชื่อของแพลตฟอร์มการทำงาน ซึ่งมักเรียกกันว่าแฝดสามเป้าหมาย วิธีง่ายๆ ในการระบุชื่อแฝดเป้าหมายคือการเรียกใช้ config.เดา สคริปต์ที่มาพร้อมกับซอร์สของแพ็คเกจมากมาย แกะแหล่ง Binutils และเรียกใช้สคริปต์: ./config.guess และสังเกตผลลัพธ์ ตัวอย่างเช่น สำหรับโปรเซสเซอร์ Intel แบบ 32 บิต ผลลัพธ์จะเป็น i686-pc-ลินุกซ์-gnu. ในระบบ 64 บิตจะเป็น x86_64-pc-ลินุกซ์-gnu.
นอกจากนี้ พึงทราบชื่อของตัวเชื่อมโยงแบบไดนามิกของแพลตฟอร์ม ซึ่งมักเรียกกันว่าตัวโหลดไดนามิก (เพื่อไม่ให้สับสนกับตัวเชื่อมโยงมาตรฐาน ld ซึ่งเป็นส่วนหนึ่งของ Binutils) ตัวเชื่อมโยงแบบไดนามิกที่จัดเตรียมโดย Glibc จะค้นหาและโหลดไลบรารีที่แบ่งใช้ซึ่งโปรแกรมต้องการ เตรียมโปรแกรมให้ทำงาน จากนั้นจึงเรียกใช้ ชื่อของตัวเชื่อมโยงแบบไดนามิกสำหรับเครื่อง Intel รุ่น 32 บิตจะเป็น ld-linux.so.2 (ld-linux-x86-64.so.2 สำหรับระบบ 64 บิต) วิธีที่แน่นอนในการกำหนดชื่อของตัวเชื่อมโยงแบบไดนามิกคือการตรวจสอบไบนารีแบบสุ่มจากระบบโฮสต์โดยการเรียกใช้: readelf -l | ล่าม grep และสังเกตผลลัพธ์ ข้อมูลอ้างอิงที่เชื่อถือได้ซึ่งครอบคลุมทุกแพลตฟอร์มอยู่ใน shlib-รุ่น ไฟล์ในรูทของแผนผังต้นทาง Glibc
ประเด็นทางเทคนิคที่สำคัญบางประการเกี่ยวกับวิธีการทำงานของ Chapter 5 build:
• ปรับเปลี่ยนชื่อแพลตฟอร์มการทำงานเล็กน้อย โดยเปลี่ยนช่อง "ผู้ขาย" เป้าหมายแฝดสามทาง LFS_TGT ตรวจสอบให้แน่ใจว่าบิลด์แรกของ Binutils และ GCC สร้าง cross-linker และ cross-compiler ที่เข้ากันได้ แทนที่จะสร้างไบนารีสำหรับสถาปัตยกรรมอื่น cross-linker และ cross-compiler จะสร้างไบนารีที่เข้ากันได้กับฮาร์ดแวร์ปัจจุบัน
• ไลบรารีชั่วคราวถูกคอมไพล์ข้าม เนื่องจากครอสคอมไพเลอร์โดยธรรมชาติไม่สามารถพึ่งพาสิ่งใดจากระบบโฮสต์ได้ วิธีการนี้จึงขจัดการปนเปื้อนที่อาจเกิดขึ้นของระบบเป้าหมายโดยลดโอกาสที่ส่วนหัวหรือไลบรารีจากโฮสต์จะถูกรวมเข้ากับเครื่องมือใหม่ การคอมไพล์ข้ามยังช่วยให้สามารถสร้างไลบรารีทั้งแบบ 32 บิตและ 64 บิตบนฮาร์ดแวร์ที่มีความสามารถ 64 บิตได้
• การจัดการซอร์ส GCC อย่างระมัดระวังจะบอกคอมไพเลอร์ว่าตัวลิงก์แบบไดนามิกเป้าหมายใดจะถูกใช้
ติดตั้ง Binutils ก่อนเพราะ กำหนดค่า การรันทั้ง GCC และ Glibc จะทำการทดสอบคุณสมบัติต่างๆ บนแอสเซมเบลอร์และลิงเกอร์เพื่อกำหนดคุณสมบัติซอฟต์แวร์ที่จะเปิดหรือปิดใช้งาน สิ่งนี้สำคัญกว่าที่ใครจะเข้าใจในตอนแรก GCC หรือ Glibc ที่กำหนดค่าไม่ถูกต้องอาจส่งผลให้เกิด toolchain ที่เสียหาย ซึ่งผลกระทบของการแตกหักดังกล่าวอาจไม่ปรากฏขึ้นจนกว่าจะสิ้นสุดการสร้างของการกระจายทั้งหมด ความล้มเหลวของชุดทดสอบมักจะเน้นข้อผิดพลาดนี้ก่อนที่จะทำงานเพิ่มเติมมากเกินไป
Binutils ติดตั้งแอสเซมเบลอร์และลิงเกอร์ในสองตำแหน่ง /เครื่องมือ/ถัง และ /tools/$LFS_TGT/bin. เครื่องมือในที่หนึ่งเชื่อมโยงอย่างหนักกับอีกที่หนึ่ง แง่มุมที่สำคัญของตัวเชื่อมโยงคือลำดับการค้นหาในห้องสมุด สามารถดูรายละเอียดข้อมูลได้จาก ld โดยผ่านมัน --รายละเอียด ธง. ตัวอย่างเช่น an ld --verbose | grep ค้นหา จะแสดงเส้นทางการค้นหาปัจจุบันและลำดับของพวกเขา มันแสดงให้เห็นว่าไฟล์ใดที่เชื่อมโยงโดย ld โดยการรวบรวมโปรแกรมจำลองและผ่าน --รายละเอียด เปลี่ยนไปใช้ตัวเชื่อมโยง ตัวอย่างเช่น, gcc dummy.c -Wl,--verbose 2>&1
| grep สำเร็จจะแสดงไฟล์ทั้งหมดที่เปิดได้สำเร็จในระหว่างการลิงก์
แพ็คเกจถัดไปที่ติดตั้งคือ GCC ตัวอย่างของสิ่งที่สามารถเห็นได้ในระหว่างการดำเนินการของ กำหนดค่า คือ:
กำลังตรวจสอบสิ่งที่แอสเซมเบลอร์ที่จะใช้... /tools/i686-lfs-linux-gnu/bin/as กำลังตรวจสอบตัวเชื่อมโยงที่จะใช้... /tools/i686-lfs-linux-gnu/bin/ld
กำลังตรวจสอบสิ่งที่แอสเซมเบลอร์ที่จะใช้... /tools/i686-lfs-linux-gnu/bin/as กำลังตรวจสอบตัวเชื่อมโยงที่จะใช้... /tools/i686-lfs-linux-gnu/bin/ld
นี่เป็นสิ่งสำคัญสำหรับเหตุผลที่กล่าวข้างต้น นอกจากนี้ยังแสดงให้เห็นว่าสคริปต์กำหนดค่าของ GCC ไม่ได้ค้นหาไดเรกทอรี PATH เพื่อค้นหาเครื่องมือที่จะใช้ อย่างไรก็ตาม ในระหว่างการใช้งานจริงของ gcc ไม่จำเป็นต้องใช้เส้นทางการค้นหาเดียวกัน เพื่อหาว่าตัวเชื่อมโยงมาตรฐานตัวใด gcc จะใช้เรียกใช้: gcc -print-prog-name=ld.
สามารถดูรายละเอียดข้อมูลได้จาก gcc โดยผ่านมัน -v ตัวเลือกบรรทัดคำสั่งขณะคอมไพล์โปรแกรมจำลอง ตัวอย่างเช่น, gcc -v หุ่นจำลอง.c จะแสดงข้อมูลโดยละเอียดเกี่ยวกับขั้นตอนก่อนโปรเซสเซอร์ การคอมไพล์ และการประกอบ รวมถึง gccรวมเส้นทางการค้นหาและลำดับ
การติดตั้งครั้งถัดไปคือส่วนหัว Linux API ที่ผ่านการฆ่าเชื้อแล้ว สิ่งเหล่านี้ทำให้ไลบรารี C มาตรฐาน (Glibc) สามารถเชื่อมต่อกับคุณลักษณะต่างๆ ที่เคอร์เนลลินุกซ์มีให้
แพ็คเกจถัดไปที่ติดตั้งคือ Glibc ข้อควรพิจารณาที่สำคัญที่สุดสำหรับการสร้าง Glibc คือคอมไพเลอร์ เครื่องมือไบนารี และส่วนหัวของเคอร์เนล โดยทั่วไปแล้วคอมไพเลอร์จะไม่เป็นปัญหาเนื่องจาก Glibc จะใช้คอมไพเลอร์ที่เกี่ยวข้องกับ --เจ้าภาพ พารามิเตอร์ส่งผ่านไปยังสคริปต์กำหนดค่า เช่นในกรณีของเราคอมไพเลอร์จะเป็น i686-lfs-ลินุกซ์-gnu-gcc. เครื่องมือไบนารีและส่วนหัวของเคอร์เนลอาจซับซ้อนกว่านี้เล็กน้อย ดังนั้นอย่าเสี่ยงและใช้สวิตช์กำหนดค่าที่มีอยู่เพื่อบังคับใช้การเลือกที่ถูกต้อง หลังจากการวิ่งของ กำหนดค่า, ตรวจสอบเนื้อหาของ config.make แฟ้มใน glibc สร้าง ไดเรกทอรีสำหรับรายละเอียดที่สำคัญทั้งหมด สังเกตการใช้ CC="i686-lfs-gnu-gcc" เพื่อควบคุมเครื่องมือไบนารีที่ใช้และการใช้ -nostdinc และ -ไอซิสเต็ม ตั้งค่าสถานะเพื่อควบคุมเส้นทางการค้นหารวมของคอมไพเลอร์ รายการเหล่านี้เน้นย้ำถึงแง่มุมที่สำคัญของแพ็คเกจ Glibc—ซึ่งมีความพอเพียงในแง่ของเครื่องจักรในการสร้าง และโดยทั่วไปจะไม่พึ่งพาค่าเริ่มต้นของ toolchain
ในระหว่างการผ่านครั้งที่สองของ Binutils เราสามารถใช้ --with-lib-เส้นทาง กำหนดค่าสวิตช์เพื่อควบคุม ldเส้นทางการค้นหาห้องสมุดของ
สำหรับการส่ง GCC ครั้งที่สอง แหล่งที่มาของ GCC จะต้องได้รับการแก้ไขเพื่อบอกให้ GCC ใช้ตัวเชื่อมโยงแบบไดนามิกใหม่ การไม่ทำเช่นนั้นจะส่งผลให้โปรแกรม GCC เองมีชื่อของตัวเชื่อมโยงแบบไดนามิกจากระบบโฮสต์ / lib ไดเร็กทอรีที่ฝังอยู่ในนั้นซึ่งจะเอาชนะเป้าหมายในการหนีจากโฮสต์ จากจุดนี้เป็นต้นไป toolchain หลักจะประกอบด้วยตัวเองและโฮสต์ในตัวเอง ส่วนที่เหลือของแพ็คเกจบทที่ 5 ทั้งหมดสร้างขึ้นจาก Glibc ใน /เครื่องมือ.
เมื่อเข้าสู่สภาวะแวดล้อม chroot ในบทที่ 6 แพ็กเกจหลักชุดแรกที่จะติดตั้งคือ Glibc เนื่องจากมีลักษณะพอเพียงตามที่กล่าวมาข้างต้น เมื่อติดตั้ง Glibc นี้ลงใน / usrเราจะดำเนินการเปลี่ยนค่าเริ่มต้นของ toolchain อย่างรวดเร็ว จากนั้นจึงดำเนินการสร้างระบบ LFS เป้าหมายที่เหลือ