การติดตั้ง GCC จาก Linux ตั้งแต่เริ่มต้นโดย OnWorks

ข้ามไปที่เนื้อหา

<ก่อนหน้านี้ | Contents | ถัดไป>

6.21.1. การติดตั้ง GCC

หากสร้างบน x86_64 ให้เปลี่ยนชื่อไดเร็กทอรีเริ่มต้นสำหรับไลบรารี 64 บิตเป็น "lib":

กรณี $(uname -m) ใน x86_64)

sed -e '/m64=/s/lib64/lib/' \

-i.orig gcc/config/i386/t-linux64

;;

ว่า C

กรณี $(uname -m) ใน x86_64)

sed -e '/m64=/s/lib64/lib/' \

-i.orig gcc/config/i386/t-linux64

;;

ว่า C

เอกสาร GCC แนะนำให้สร้าง GCC ในไดเร็กทอรีบิลด์เฉพาะ:

mkdir -v บิลด์ซีดี

เตรียม GCC สำหรับการรวบรวม:

SED=เส็ด \

../กำหนดค่า --prefix=/usr \

--เปิดใช้งานภาษา=c,c++ \

--disable-multilib \

--disable-bootstrap \

--กับ-ระบบ-zlib

SED=เส็ด \

../กำหนดค่า --prefix=/usr \

--เปิดใช้งานภาษา=c,c++ \

--disable-multilib \

--disable-bootstrap \

--กับ-ระบบ-zlib

โปรดทราบว่าสำหรับภาษาอื่น มีข้อกำหนดเบื้องต้นบางอย่างที่ยังไม่พร้อมใช้งาน ดูหนังสือ BLFS สำหรับคำแนะนำเกี่ยวกับวิธีสร้างภาษาที่รองรับทั้งหมดของ GCC

ความหมายของพารามิเตอร์กำหนดค่าใหม่:

SED=เส็ด

การตั้งค่าตัวแปรสภาพแวดล้อมนี้จะป้องกันพาธแบบฮาร์ดโค้ดไปยัง /tools/bin/sed

--กับ-ระบบ-zlib

สวิตช์นี้บอกให้ GCC ลิงก์ไปยังสำเนาของไลบรารี Zlib ที่ติดตั้งระบบ แทนที่จะเป็นสำเนาภายในของตัวเอง

ภาพ

รวบรวมแพ็คเกจ:

ทำ

สำคัญ

ในส่วนนี้ ชุดทดสอบสำหรับ GCC ถือว่ามีความสำคัญ ห้ามข้ามไม่ว่ากรณีใดๆ

สำคัญ

ในส่วนนี้ ชุดทดสอบสำหรับ GCC ถือว่ามีความสำคัญ ห้ามข้ามไม่ว่ากรณีใดๆ

การทดสอบหนึ่งชุดในชุดทดสอบ GCC เป็นที่ทราบกันดีว่าทำให้สแต็กหมด ดังนั้นให้เพิ่มขนาดสแต็กก่อนที่จะรันการทดสอบ:

ยูลิมิต -s 32768

ทดสอบผลลัพธ์ในฐานะผู้ใช้ที่ไม่มีสิทธิพิเศษ แต่อย่าหยุดที่ข้อผิดพลาด:

chown -Rv ไม่มีใคร

su none -s /bin/bash -c "PATH=$PATH make -k check"

chown -Rv ไม่มีใคร

su none -s /bin/bash -c "PATH=$PATH make -k check"

หากต้องการรับสรุปผลชุดทดสอบ ให้เรียกใช้:

../contrib/test_summary

สำหรับข้อมูลสรุปเท่านั้น ให้ไพพ์เอาต์พุตผ่าน grep -A7 ซัม.

สามารถเปรียบเทียบผลลัพธ์กับผลลัพธ์ได้ที่ http://www.linuxfromscratch.org/lfs/build-logs/9.0/ และ https://gcc.gnu org/ml/gcc-testresults/.

การทดสอบหกรายการที่เกี่ยวข้องกับ get_time นั้นล้มเหลว เห็นได้ชัดว่าสิ่งเหล่านี้เกี่ยวข้องกับสถานที่ en_HK

การทดสอบสองรายการชื่อ lookup.cc และ reverse.cc ใน Experimental/net นั้นล้มเหลวในสภาพแวดล้อม LFS chroot เนื่องจากต้องใช้ /etc/hosts และ iana-etc

การทดสอบสองรายการชื่อ pr57193.c และ pr90178.c ล้มเหลว

ความล้มเหลวที่ไม่คาดคิดบางอย่างไม่สามารถหลีกเลี่ยงได้เสมอไป นักพัฒนา GCC มักจะตระหนักถึงปัญหาเหล่านี้ แต่ยังไม่ได้แก้ไข เว้นแต่ผลการทดสอบจะแตกต่างอย่างมากจาก URL ด้านบน คุณสามารถดำเนินการต่อได้อย่างปลอดภัย

ติดตั้งแพ็คเกจและลบไดเร็กทอรีที่ไม่จำเป็น:

ให้ติดตั้ง

rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/9.2.0/include-fixed/bits/

ให้ติดตั้ง

rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/9.2.0/include-fixed/bits/

ไดเร็กทอรีบิลด์ GCC เป็นของ ไม่มีใคร ตอนนี้และความเป็นเจ้าของไดเร็กทอรีส่วนหัวที่ติดตั้ง (และเนื้อหา) จะไม่ถูกต้อง เปลี่ยนความเป็นเจ้าของเป็น ราก ผู้ใช้และกลุ่ม:

chown -v -R รูท: รูท \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-คงที่}

chown -v -R รูท: รูท \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-คงที่}

สร้าง symlink ที่ FHS ต้องการด้วยเหตุผล "ในอดีต"

ln -sv ../usr/bin/cpp /lib

หลายแพ็คเกจใช้ชื่อ cc เพื่อเรียกคอมไพเลอร์ C เพื่อให้เป็นไปตามแพ็คเกจเหล่านั้น ให้สร้าง symlink:

ln -sv gcc /usr/bin/cc

เพิ่ม symlink ที่เข้ากันได้เพื่อเปิดใช้งานการสร้างโปรแกรมด้วย Link Time Optimization (LTO):

ติดตั้ง -v -dm755 /usr/lib/bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/9.2.0/liblto_plugin.so \

/usr/lib/bfd-ปลั๊กอิน/

ติดตั้ง -v -dm755 /usr/lib/bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/9.2.0/liblto_plugin.so \

/usr/lib/bfd-ปลั๊กอิน/

ตอนนี้ Toolchain ขั้นสุดท้ายของเราพร้อมแล้ว สิ่งสำคัญคือต้องตรวจสอบให้แน่ใจอีกครั้งว่าการคอมไพล์และลิงก์จะทำงานตามที่คาดไว้ เราทำสิ่งนี้โดยทำการตรวจสุขภาพจิตแบบเดียวกับที่เราทำในตอนต้น:

echo 'int main(){}' > dummy.c

cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': / lib'

echo 'int main(){}' > dummy.c

cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': / lib'

ไม่ควรมีข้อผิดพลาดและผลลัพธ์ของคำสั่งสุดท้ายจะเป็น (อนุญาตให้ใช้ความแตกต่างเฉพาะแพลตฟอร์มในชื่อตัวเชื่อมโยงแบบไดนามิก):

[กำลังขอโปรแกรมล่าม: /lib64/ld-linux-x86-64.so.2]

ตอนนี้ ตรวจสอบให้แน่ใจว่าเราได้ตั้งค่าให้ใช้ไฟล์เริ่มต้นที่ถูกต้อง:

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

ผลลัพธ์ของคำสั่งสุดท้ายควรเป็น:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o สำเร็จ

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o สำเร็จ

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o สำเร็จ

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o สำเร็จ

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o สำเร็จ

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o สำเร็จ

ขึ้นอยู่กับสถาปัตยกรรมเครื่องของคุณ ด้านบนอาจแตกต่างกันเล็กน้อย ความแตกต่างมักจะเป็นชื่อของไดเร็กทอรีหลัง /usr/lib/gcc. สิ่งสำคัญที่ต้องมองหาที่นี่คือ gcc ได้พบทั้งสาม crt*.o ไฟล์ภายใต้ / usr / lib ไดเรกทอรี

ตรวจสอบว่าคอมไพเลอร์กำลังค้นหาไฟล์ส่วนหัวที่ถูกต้อง:

grep -B4 '^ /usr/include' dummy.log

คำสั่งนี้ควรส่งคืนผลลัพธ์ต่อไปนี้:

#include <...> การค้นหาเริ่มต้นที่นี่:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/รวม

/usr/local/include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / รวม

#include <...> การค้นหาเริ่มต้นที่นี่:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/รวม

/usr/local/include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / รวม

อีกครั้ง โปรดทราบว่าไดเร็กทอรีที่ตั้งชื่อตาม triplet เป้าหมายของคุณอาจแตกต่างจากด้านบน ขึ้นอยู่กับสถาปัตยกรรมของคุณ

ถัดไป ตรวจสอบว่ามีการใช้ตัวเชื่อมโยงใหม่กับเส้นทางการค้นหาที่ถูกต้อง:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

การอ้างอิงถึงพาธที่มีส่วนประกอบที่มี '-linux-gnu' ควรถูกละเว้น มิฉะนั้น เอาต์พุตของคำสั่งสุดท้ายควรเป็น:

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

ระบบ 32 บิตอาจเห็นไดเร็กทอรีที่แตกต่างกันสองสามรายการ ตัวอย่างเช่น นี่คือผลลัพธ์จากเครื่อง i686:

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32")

SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32")

SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

ต่อไป ตรวจสอบให้แน่ใจว่าเราใช้ libc ที่ถูกต้อง:

grep "/lib.*/libc.so.6 " dummy.log

ผลลัพธ์ของคำสั่งสุดท้ายควรเป็น:

พยายามเปิด /lib/libc.so.6 สำเร็จ

สุดท้าย ตรวจสอบให้แน่ใจว่า GCC ใช้ตัวเชื่อมโยงแบบไดนามิกที่ถูกต้อง:

grep พบ dummy.log

ผลลัพธ์ของคำสั่งสุดท้ายควรเป็น (อนุญาตให้ใช้ความแตกต่างเฉพาะแพลตฟอร์มในชื่อตัวเชื่อมโยงแบบไดนามิก):

พบ ld-linux-x86-64.so.2 ที่ /lib/ld-linux-x86-64.so.2

หากผลลัพธ์ไม่ปรากฏตามที่แสดงด้านบนหรือไม่ได้รับเลย แสดงว่ามีบางอย่างผิดปกติอย่างร้ายแรง ตรวจสอบและย้อนขั้นตอนเพื่อดูว่าปัญหาอยู่ที่ไหนและแก้ไขให้ถูกต้อง สาเหตุที่เป็นไปได้มากที่สุดคือมีบางอย่างผิดปกติกับการปรับไฟล์ข้อมูลจำเพาะ ปัญหาใด ๆ จะต้องได้รับการแก้ไขก่อนดำเนินการตามกระบวนการต่อไป

เมื่อทุกอย่างถูกต้องแล้ว ให้ล้างไฟล์ทดสอบ:

rm -v dummy.c a.out dummy.log

สุดท้าย ย้ายไฟล์ที่วางผิดที่:

mkdir -pv /usr/share/gdb/โหลดอัตโนมัติ/usr/lib

mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib

mkdir -pv /usr/share/gdb/โหลดอัตโนมัติ/usr/lib

mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib

<ก่อนหน้านี้ | Contents | ถัดไป>