ການຕິດຕັ້ງ GCC ຈາກ Linux ຈາກ Scratch ໂດຍ OnWorks

ໃຫ້ຂ້າມໄປຫາເນື້ອໃນ

6.21.1. ການຕິດຕັ້ງ GCC

ຖ້າສ້າງໃນ x86_64, ປ່ຽນຊື່ໄດເລກະທໍລີເລີ່ມຕົ້ນສໍາລັບຫ້ອງສະຫມຸດ 64-bit ເປັນ "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 build cd build

ກະກຽມ GCC ສໍາລັບການລວບລວມ:

SED=sed \

../configure --prefix=/usr \

--enable-languages=c,c++ \

--disable-multilib \

--disable-bootstrap \

--with-system-zlib

SED=sed \

../configure --prefix=/usr \

--enable-languages=c,c++ \

--disable-multilib \

--disable-bootstrap \

--with-system-zlib

ໃຫ້ສັງເກດວ່າສໍາລັບພາສາອື່ນ, ມີຂໍ້ກໍານົດເບື້ອງຕົ້ນບາງຢ່າງທີ່ຍັງບໍ່ທັນມີ. ເບິ່ງປື້ມ BLFS ສໍາລັບຄໍາແນະນໍາກ່ຽວກັບວິທີການສ້າງພາສາທີ່ສະຫນັບສະຫນູນທັງຫມົດຂອງ GCC.

ຄວາມໝາຍຂອງຕົວກໍານົດການກຳນົດຄ່າໃໝ່:

SED=sed

ການຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມນີ້ປ້ອງກັນເສັ້ນທາງທີ່ມີລະຫັດຍາກໄປຫາ /tools/bin/sed.

--with-system-zlib

ສະວິດນີ້ບອກ GCC ໃຫ້ເຊື່ອມຕໍ່ກັບລະບົບທີ່ຕິດຕັ້ງສໍາເນົາຫ້ອງສະຫມຸດ Zlib, ແທນທີ່ຈະເປັນສໍາເນົາພາຍໃນຂອງຕົນເອງ.

ຮູບພາບເລັກນ້ອຍ

ສັງລວມຊຸດ:

ເຮັດໃຫ້

ທີ່ສໍາຄັນ

ໃນພາກນີ້, ຊຸດທົດສອບສໍາລັບ GCC ແມ່ນພິຈາລະນາທີ່ສໍາຄັນ. ຢ່າຂ້າມມັນພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມ.

ທີ່ສໍາຄັນ

ໃນພາກນີ້, ຊຸດທົດສອບສໍາລັບ GCC ແມ່ນພິຈາລະນາທີ່ສໍາຄັນ. ຢ່າຂ້າມມັນພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມ.

ການທົດສອບຊຸດໜຶ່ງໃນຊຸດທົດສອບ GCC ແມ່ນຮູ້ກັນວ່າໝົດ stack, ສະນັ້ນເພີ່ມຂະໜາດ stack ກ່ອນທີ່ຈະດໍາເນີນການທົດສອບ:

ulimit -s 32768

ທົດສອບຜົນໄດ້ຮັບເປັນຜູ້ໃຊ້ທີ່ບໍ່ມີສິດທິພິເສດ, ແຕ່ຢ່າຢຸດຢູ່ທີ່ຄວາມຜິດພາດ:

chown -Rv ບໍ່ມີໃຜ .

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

chown -Rv ບໍ່ມີໃຜ .

su nobody -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 ໃນການທົດລອງ / net ເປັນທີ່ຮູ້ຈັກທີ່ຈະລົ້ມເຫລວໃນສະພາບແວດລ້ອມ LFS chroot ເພາະວ່າພວກເຂົາຕ້ອງການ /etc/hosts ແລະ iana-etc.

ສອງການທົດສອບທີ່ມີຊື່ວ່າ pr57193.c ແລະ pr90178.c ແມ່ນຮູ້ວ່າລົ້ມເຫລວ.

ຄວາມລົ້ມເຫລວທີ່ບໍ່ຄາດຄິດບາງຢ່າງບໍ່ສາມາດຫຼີກເວັ້ນໄດ້ສະເໝີ. ຜູ້ພັດທະນາ GCC ມັກຈະຮູ້ບັນຫາເຫຼົ່ານີ້, ແຕ່ຍັງບໍ່ທັນໄດ້ແກ້ໄຂເທື່ອ. ເວັ້ນເສຍແຕ່ວ່າຜົນໄດ້ຮັບການທົດສອບແມ່ນແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຈາກ URL ຂ້າງເທິງ, ມັນປອດໄພທີ່ຈະສືບຕໍ່.

ຕິດຕັ້ງແພັກເກັດແລະເອົາໄດເລກະທໍລີທີ່ບໍ່ຈໍາເປັນອອກ:

ເຮັດໃຫ້ຕິດຕັ້ງ

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

ເຮັດໃຫ້ຕິດຕັ້ງ

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

GCC build directory ແມ່ນເປັນເຈົ້າຂອງໂດຍ ບໍ່ມີໃຜ ໃນປັດຈຸບັນແລະຄວາມເປັນເຈົ້າຂອງຂອງໄດເລກະທໍລີຫົວທີ່ຕິດຕັ້ງ (ແລະເນື້ອຫາຂອງມັນ) ຈະບໍ່ຖືກຕ້ອງ. ປ່ຽນຄວາມເປັນເຈົ້າຂອງເປັນ ຮາກ ຜູ້ໃຊ້ແລະກຸ່ມ:

chown -v -R ຮາກ:ຮາກ \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-fixed}

chown -v -R ຮາກ:ຮາກ \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-fixed}

ສ້າງ symlink ທີ່ຕ້ອງການໂດຍ FHS ສໍາລັບເຫດຜົນ "ປະຫວັດສາດ".

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

ຫລາຍແພັກເກັດໃຊ້ຊື່ cc ໂທຫາ C compiler. ເພື່ອຕອບສະໜອງການຫຸ້ມຫໍ່ເຫຼົ່ານັ້ນ, ໃຫ້ສ້າງ symlink:

ln -sv gcc /usr/bin/cc

ເພີ່ມ symlink ຄວາມເຂົ້າກັນໄດ້ເພື່ອເປີດໃຊ້ໂຄງການກໍ່ສ້າງດ້ວຍ Link Time Optimization (LTO):

ຕິດຕັ້ງ -v -dm755 /usr/lib/bfd-plugins

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

/usr/lib/bfd-plugins/

ຕິດຕັ້ງ -v -dm755 /usr/lib/bfd-plugins

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

/usr/lib/bfd-plugins/

ໃນປັດຈຸບັນທີ່ລະບົບຕ່ອງໂສ້ເຄື່ອງມືສຸດທ້າຍຂອງພວກເຮົາຢູ່ໃນສະຖານທີ່, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮັບປະກັນອີກເທື່ອຫນຶ່ງວ່າການລວບລວມແລະການເຊື່ອມໂຍງຈະເຮັດວຽກຕາມທີ່ຄາດໄວ້. ພວກເຮົາເຮັດສິ່ງນີ້ໂດຍການກວດສອບສຸຂາພິບານດຽວກັນກັບທີ່ພວກເຮົາໄດ້ເຮັດກ່ອນຫນ້ານີ້ໃນບົດ:

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 ລະບົບ.

ກວດສອບວ່າຜູ້ສັງລວມກໍາລັງຊອກຫາສໍາລັບໄຟລ໌ header ທີ່ຖືກຕ້ອງ:

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

ຄໍາສັ່ງນີ້ຄວນສົ່ງຄືນຜົນໄດ້ຮັບຕໍ່ໄປນີ້:

#include <...> ການຄົ້ນຫາເລີ່ມຕົ້ນທີ່ນີ້:

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

/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/include

/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-bit ອາດຈະເຫັນໄດເລກະທໍລີທີ່ແຕກຕ່າງກັນຈໍານວນຫນ້ອຍ. ຕົວຢ່າງ, ນີ້ແມ່ນຜົນຜະລິດຈາກເຄື່ອງ 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

ຖ້າຜົນຜະລິດບໍ່ປາກົດດັ່ງທີ່ສະແດງຢູ່ຂ້າງເທິງຫຼືບໍ່ໄດ້ຮັບທັງຫມົດ, ຫຼັງຈາກນັ້ນບາງສິ່ງບາງຢ່າງແມ່ນຜິດພາດຢ່າງຮ້າຍແຮງ. ສືບສວນແລະ retrace ຂັ້ນຕອນເພື່ອຊອກຫາບ່ອນທີ່ບັນຫາແມ່ນແລະແກ້ໄຂມັນ. ເຫດຜົນຫຼາຍທີ່ສຸດແມ່ນວ່າມີບາງຢ່າງຜິດພາດກັບການປັບໄຟລ໌ specs. ບັນຫາໃດໆຈະຕ້ອງໄດ້ແກ້ໄຂກ່ອນທີ່ຈະສືບຕໍ່ຂະບວນການ.

ເມື່ອທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢ່າງຖືກຕ້ອງ, ເຮັດຄວາມສະອາດໄຟລ໌ທົດສອບ:

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

ສຸດທ້າຍ, ຍ້າຍໄຟລ໌ທີ່ໃສ່ຜິດ:

mkdir -pv /usr/share/gdb/auto-load/usr/lib

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

mkdir -pv /usr/share/gdb/auto-load/usr/lib

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