5.2. ບັນທຶກດ້ານວິຊາການຂອງລະບົບຕ່ອງໂສ້
ພາກນີ້ອະທິບາຍບາງເຫດຜົນແລະລາຍລະອຽດດ້ານວິຊາການທີ່ຢູ່ເບື້ອງຫລັງວິທີການກໍ່ສ້າງໂດຍລວມ. ມັນບໍ່ຈໍາເປັນທີ່ຈະເຂົ້າໃຈທັນທີທັນໃດທຸກສິ່ງທຸກຢ່າງໃນພາກນີ້. ຂໍ້ມູນສ່ວນໃຫຍ່ນີ້ຈະຈະແຈ້ງຂຶ້ນຫຼັງຈາກປະຕິບັດການກໍ່ສ້າງຕົວຈິງ. ພາກສ່ວນນີ້ສາມາດອ້າງອີງໄດ້ທຸກເວລາໃນລະຫວ່າງຂະບວນການ.
ເປົ້າຫມາຍໂດຍລວມຂອງບົດທີ 5 ແມ່ນການຜະລິດພື້ນທີ່ຊົ່ວຄາວທີ່ປະກອບດ້ວຍຊຸດເຄື່ອງມືທີ່ຮູ້ຈັກດີທີ່ສາມາດແຍກອອກຈາກລະບົບເຈົ້າພາບ. ໂດຍການນໍາໃຊ້ roາກເຜັດ, ຄໍາສັ່ງໃນບົດທີ່ຍັງເຫຼືອຈະຖືກບັນຈຸຢູ່ໃນສະພາບແວດລ້ອມນັ້ນ, ຮັບປະກັນການກໍ່ສ້າງທີ່ສະອາດ, ບໍ່ມີບັນຫາຂອງລະບົບ LFS ເປົ້າຫມາຍ. ຂະບວນການກໍ່ສ້າງໄດ້ຖືກອອກແບບເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ຜູ້ອ່ານໃຫມ່ແລະໃຫ້ມູນຄ່າການສຶກສາທີ່ສຸດໃນເວລາດຽວກັນ.
ຫມາຍເຫດ
ກ່ອນທີ່ຈະສືບຕໍ່, ຈົ່ງຮູ້ເຖິງຊື່ຂອງເວທີການເຮັດວຽກ, ມັກຈະເອີ້ນວ່າ triplet ເປົ້າຫມາຍ. ວິທີທີ່ງ່າຍດາຍໃນການກໍານົດຊື່ຂອງ triplet ເປົ້າຫມາຍແມ່ນເພື່ອດໍາເນີນການ config.guess script ທີ່ມາພ້ອມກັບແຫຼ່ງສໍາລັບຫລາຍແພັກເກັດ. Unpack ແຫຼ່ງ Binutils ແລະແລ່ນສະຄິບ: ./config.guess ແລະສັງເກດຜົນຜະລິດ. ຕົວຢ່າງ, ສໍາລັບໂປເຊດເຊີ Intel 32-bit, ຜົນຜະລິດຈະເປັນ i686-pc-linux-gnu. ໃນລະບົບ 64-bit ມັນຈະເປັນ x86_64-pc-linux-gnu.
ຍັງໄດ້ຮັບຮູ້ຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວຂອງເວທີ, ມັກຈະເອີ້ນວ່າຕົວໂຫຼດແບບເຄື່ອນໄຫວ (ບໍ່ຄວນສັບສົນກັບຕົວເຊື່ອມຕໍ່ມາດຕະຖານ. ld ນັ້ນແມ່ນສ່ວນຫນຶ່ງຂອງ Binutils). ຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວທີ່ສະຫນອງໂດຍ Glibc ຊອກຫາແລະໂຫຼດຫ້ອງສະຫມຸດທີ່ໃຊ້ຮ່ວມກັນທີ່ຕ້ອງການໂດຍໂຄງການ, ກະກຽມໂຄງການທີ່ຈະດໍາເນີນການ, ແລະຫຼັງຈາກນັ້ນດໍາເນີນການມັນ. ຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວສໍາລັບເຄື່ອງຈັກ Intel 32-bit ຈະເປັນ ld-linux.so.2 (ld-linux-x86-64.so.2 ສໍາລັບລະບົບ 64-bit). ວິທີທີ່ແນ່ນອນເພື່ອກໍານົດຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວແມ່ນເພື່ອກວດກາເບິ່ງ binary ແບບສຸ່ມຈາກລະບົບເຈົ້າພາບໂດຍການແລ່ນ: readelf -l | ນາຍພາສາ grep ແລະສັງເກດເຫັນຜົນຜະລິດ. ການອ້າງອິງ authoritative ກວມເອົາທຸກເວທີແມ່ນຢູ່ໃນ shlib-versions ໄຟລ໌ຢູ່ໃນຮາກຂອງຕົ້ນໄມ້ແຫຼ່ງ Glibc.
ຫມາຍເຫດ
ກ່ອນທີ່ຈະສືບຕໍ່, ຈົ່ງຮູ້ເຖິງຊື່ຂອງເວທີການເຮັດວຽກ, ມັກຈະເອີ້ນວ່າ triplet ເປົ້າຫມາຍ. ວິທີທີ່ງ່າຍດາຍໃນການກໍານົດຊື່ຂອງ triplet ເປົ້າຫມາຍແມ່ນເພື່ອດໍາເນີນການ config.guess script ທີ່ມາພ້ອມກັບແຫຼ່ງສໍາລັບຫລາຍແພັກເກັດ. Unpack ແຫຼ່ງ Binutils ແລະແລ່ນສະຄິບ: ./config.guess ແລະສັງເກດຜົນຜະລິດ. ຕົວຢ່າງ, ສໍາລັບໂປເຊດເຊີ Intel 32-bit, ຜົນຜະລິດຈະເປັນ i686-pc-linux-gnu. ໃນລະບົບ 64-bit ມັນຈະເປັນ x86_64-pc-linux-gnu.
ຍັງໄດ້ຮັບຮູ້ຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວຂອງເວທີ, ມັກຈະເອີ້ນວ່າຕົວໂຫຼດແບບເຄື່ອນໄຫວ (ບໍ່ຄວນສັບສົນກັບຕົວເຊື່ອມຕໍ່ມາດຕະຖານ. ld ນັ້ນແມ່ນສ່ວນຫນຶ່ງຂອງ Binutils). ຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວທີ່ສະຫນອງໂດຍ Glibc ຊອກຫາແລະໂຫຼດຫ້ອງສະຫມຸດທີ່ໃຊ້ຮ່ວມກັນທີ່ຕ້ອງການໂດຍໂຄງການ, ກະກຽມໂຄງການທີ່ຈະດໍາເນີນການ, ແລະຫຼັງຈາກນັ້ນດໍາເນີນການມັນ. ຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວສໍາລັບເຄື່ອງຈັກ Intel 32-bit ຈະເປັນ ld-linux.so.2 (ld-linux-x86-64.so.2 ສໍາລັບລະບົບ 64-bit). ວິທີທີ່ແນ່ນອນເພື່ອກໍານົດຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວແມ່ນເພື່ອກວດກາເບິ່ງ binary ແບບສຸ່ມຈາກລະບົບເຈົ້າພາບໂດຍການແລ່ນ: readelf -l | ນາຍພາສາ grep ແລະສັງເກດເຫັນຜົນຜະລິດ. ການອ້າງອິງ authoritative ກວມເອົາທຸກເວທີແມ່ນຢູ່ໃນ shlib-versions ໄຟລ໌ຢູ່ໃນຮາກຂອງຕົ້ນໄມ້ແຫຼ່ງ Glibc.
ບາງຈຸດດ້ານວິຊາການຫຼັກຂອງວິທີການສ້າງບົດທີ 5 ເຮັດວຽກແນວໃດ:
• ການປັບປ່ຽນຊື່ຂອງແພລະຕະຟອມການເຮັດວຽກເລັກນ້ອຍ, ໂດຍການປ່ຽນແປງ "ຜູ້ຂາຍ" ເປົ້າໝາຍພາກສະຫນາມ triplet ໂດຍວິທີການ. LFS_TGT ຕົວແປ, ຮັບປະກັນວ່າການສ້າງ Binutils ທໍາອິດແລະ GCC ຜະລິດ cross-linker ແລະ cross-compiler ທີ່ເຂົ້າກັນໄດ້. ແທນທີ່ຈະຜະລິດ binaries ສໍາລັບສະຖາປັດຕະຍະກໍາອື່ນ, cross-linker ແລະ cross-compiler ຈະຜະລິດ binaries ທີ່ເຂົ້າກັນໄດ້ກັບຮາດແວໃນປະຈຸບັນ.
• ຫໍສະໝຸດຊົ່ວຄາວໄດ້ຖືກລວບລວມຂ້າມ. ເນື່ອງຈາກວ່າ cross-compiler ໂດຍທໍາມະຊາດຂອງມັນບໍ່ສາມາດອີງໃສ່ສິ່ງໃດກໍ່ຕາມຈາກລະບົບໂຮດຂອງມັນ, ວິທີການນີ້ກໍາຈັດການປົນເປື້ອນຂອງລະບົບເປົ້າຫມາຍໂດຍການຫຼຸດຜ່ອນໂອກາດຂອງ headers ຫຼືຫ້ອງສະຫມຸດຈາກເຈົ້າພາບທີ່ຖືກລວມເຂົ້າໃນເຄື່ອງມືໃຫມ່. ການລວບລວມຂໍ້ມູນຂ້າມຍັງຊ່ວຍໃຫ້ຄວາມເປັນໄປໄດ້ຂອງການສ້າງຫ້ອງສະຫມຸດທັງ 32-bit ແລະ 64-bit ໃນຮາດແວທີ່ມີຄວາມສາມາດ 64-bit.
• ການຫມູນໃຊ້ຢ່າງລະມັດລະວັງຂອງແຫຼ່ງ GCC ບອກຜູ້ລວບລວມຂໍ້ມູນວ່າຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວເປົ້າຫມາຍໃດຈະຖືກໃຊ້.
Binutils ໄດ້ຖືກຕິດຕັ້ງທໍາອິດເພາະວ່າ configure ແລ່ນຂອງທັງ GCC ແລະ Glibc ດໍາເນີນການທົດສອບຄຸນສົມບັດຕ່າງໆໃນຕົວປະກອບແລະຕົວເຊື່ອມຕໍ່ເພື່ອກໍານົດຄຸນສົມບັດຂອງຊອບແວທີ່ຈະເປີດໃຊ້ຫຼືປິດການໃຊ້ງານ. ນີ້ແມ່ນສິ່ງສໍາຄັນຫຼາຍກ່ວາທີ່ຄົນທໍາອິດອາດຈະຮັບຮູ້. GCC ຫຼື Glibc ທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງສາມາດສົ່ງຜົນໃຫ້ລະບົບຕ່ອງໂສ້ເຄື່ອງມືທີ່ແຕກຫັກເລັກນ້ອຍ, ບ່ອນທີ່ຜົນກະທົບຂອງການແຕກຫັກດັ່ງກ່າວອາດຈະບໍ່ປາກົດຈົນກ່ວາໃກ້ສິ້ນສຸດການສ້າງການແຈກຢາຍທັງຫມົດ. ຄວາມລົ້ມເຫຼວຂອງຊຸດທົດສອບປົກກະຕິແລ້ວຈະເນັ້ນໃສ່ຄວາມຜິດພາດນີ້ກ່ອນທີ່ຈະເຮັດວຽກເພີ່ມເຕີມຫຼາຍເກີນໄປ.
Binutils ຕິດຕັ້ງຕົວປະກອບແລະຕົວເຊື່ອມຕໍ່ຂອງມັນຢູ່ໃນສອງສະຖານທີ່, /tools/bin ແລະ /tools/$LFS_TGT/bin. ເຄື່ອງມືຢູ່ໃນສະຖານທີ່ຫນຶ່ງແມ່ນຍາກທີ່ຈະເຊື່ອມຕໍ່ກັບບ່ອນອື່ນ. ລັກສະນະທີ່ສໍາຄັນຂອງຕົວເຊື່ອມຕໍ່ແມ່ນຄໍາສັ່ງຄົ້ນຫາຫ້ອງສະຫມຸດຂອງມັນ. ຂໍ້ມູນລະອຽດສາມາດໄດ້ຮັບຈາກ ld ໂດຍຜ່ານການມັນ -- verbose ທຸງ. ຕົວຢ່າງ, ເປັນ ld --verbose | grep ຄົ້ນຫາ ຈະສະແດງໃຫ້ເຫັນເຖິງເສັ້ນທາງຄົ້ນຫາໃນປະຈຸບັນແລະຄໍາສັ່ງຂອງພວກເຂົາ. ມັນສະແດງໃຫ້ເຫັນວ່າໄຟລ໌ໃດຖືກເຊື່ອມຕໍ່ໂດຍ ld ໂດຍການລວບລວມໂຄງການ dummy ແລະຜ່ານ -- verbose ສະຫຼັບໄປຫາຕົວເຊື່ອມຕໍ່. ຍົກຕົວຢ່າງ, gcc dummy.c -Wl,--verbose 2>&1
| grep ສໍາເລັດຈະສະແດງໄຟລ໌ທັງຫມົດເປີດສົບຜົນສໍາເລັດໃນລະຫວ່າງການເຊື່ອມຕໍ່.
ຊຸດຕໍ່ໄປທີ່ຕິດຕັ້ງແມ່ນ GCC. ຕົວຢ່າງຂອງສິ່ງທີ່ສາມາດເຫັນໄດ້ໃນລະຫວ່າງການດໍາເນີນການຂອງມັນ configure ແມ່ນ:
ກຳລັງກວດສອບຕົວເຊື່ອມຕໍ່ອັນໃດທີ່ຈະໃຊ້... /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
ນີ້ແມ່ນສໍາຄັນສໍາລັບເຫດຜົນທີ່ໄດ້ກ່າວມາຂ້າງເທິງ. ມັນຍັງສະແດງໃຫ້ເຫັນວ່າ script configure ຂອງ GCC ບໍ່ໄດ້ຄົ້ນຫາໄດເລກະທໍລີ PATH ເພື່ອຊອກຫາເຄື່ອງມືທີ່ຈະໃຊ້. ຢ່າງໃດກໍຕາມ, ໃນໄລຍະການດໍາເນີນງານຕົວຈິງຂອງ gcc ຕົວຂອງມັນເອງ, ເສັ້ນທາງຄົ້ນຫາດຽວກັນບໍ່ຈໍາເປັນຕ້ອງຖືກນໍາໃຊ້. ເພື່ອຊອກຫາຕົວເຊື່ອມຕໍ່ມາດຕະຖານໃດ gcc ຈະໃຊ້, ແລ່ນ: gcc -print-prog-name=ld.
ຂໍ້ມູນລະອຽດສາມາດໄດ້ຮັບຈາກ gcc ໂດຍຜ່ານການມັນ -v ທາງເລືອກແຖວຄໍາສັ່ງໃນຂະນະທີ່ລວບລວມໂຄງການ dummy. ຍົກຕົວຢ່າງ, gcc -v dummy.c ຈະສະແດງຂໍ້ມູນລາຍລະອຽດກ່ຽວກັບ preprocessor, ການລວບລວມ, ແລະຂັ້ນຕອນການປະກອບ, ລວມທັງ gcc's ລວມເອົາເສັ້ນທາງຄົ້ນຫາແລະຄໍາສັ່ງຂອງພວກເຂົາ.
ການຕິດຕັ້ງຕໍ່ໄປແມ່ນສ່ວນຫົວ Linux API ທີ່ຖືກອະນາໄມ. ເຫຼົ່ານີ້ອະນຸຍາດໃຫ້ຫ້ອງສະຫມຸດ C ມາດຕະຖານ (Glibc) ໂຕ້ຕອບກັບຄຸນສົມບັດທີ່ Linux kernel ຈະສະຫນອງ.
ຊຸດຕໍ່ໄປທີ່ຕິດຕັ້ງແມ່ນ Glibc. ການພິຈາລະນາທີ່ສໍາຄັນທີ່ສຸດສໍາລັບການກໍ່ສ້າງ Glibc ແມ່ນ compiler, ເຄື່ອງມື binary, ແລະ kernel headers. ໂດຍທົ່ວໄປແລ້ວ compiler ບໍ່ແມ່ນບັນຫາເນື່ອງຈາກ Glibc ຈະໃຊ້ compiler ທີ່ກ່ຽວຂ້ອງກັບ -ເຈົ້າພາບ ພາລາມິເຕີທີ່ຖືກສົ່ງໄປຫາ script configure ຂອງມັນ; eg ໃນກໍລະນີຂອງພວກເຮົາ, compiler ຈະເປັນ i686-lfs-linux-gnu-gcc. ເຄື່ອງມືຖານສອງ ແລະສ່ວນຫົວຂອງແກ່ນສາມາດສັບສົນຫຼາຍ. ດັ່ງນັ້ນ, ບໍ່ມີຄວາມສ່ຽງແລະໃຊ້ປຸ່ມປັບຄ່າທີ່ມີຢູ່ເພື່ອບັງຄັບການເລືອກທີ່ຖືກຕ້ອງ. ຫຼັງຈາກການດໍາເນີນການຂອງ configure, ກວດເບິ່ງເນື້ອໃນຂອງ config.make ໄຟລ໌ໃນ glibc-build ໄດເລກະທໍລີສໍາລັບລາຍລະອຽດທີ່ສໍາຄັນທັງຫມົດ. ຫມາຍເຫດການນໍາໃຊ້ຂອງ CC="i686-lfs-gnu-gcc" ການຄວບຄຸມທີ່ເຄື່ອງມື binary ໄດ້ຖືກນໍາໃຊ້ແລະການນໍາໃຊ້ຂອງ -nostdinc ແລະ - ລະບົບ ທຸງເພື່ອຄວບຄຸມ compiler ຂອງປະກອບມີເສັ້ນທາງຄົ້ນຫາ. ລາຍການເຫຼົ່ານີ້ຊີ້ໃຫ້ເຫັນເຖິງລັກສະນະທີ່ສໍາຄັນຂອງຊຸດ Glibc - ມັນມີຄວາມພຽງພໍໃນຕົວຂອງເຄື່ອງຈັກໃນການກໍ່ສ້າງຂອງມັນແລະໂດຍທົ່ວໄປແລ້ວບໍ່ໄດ້ອີງໃສ່ການເລີ່ມຕົ້ນຂອງລະບົບຕ່ອງໂສ້ເຄື່ອງມື.
ໃນໄລຍະທີສອງຂອງ Binutils, ພວກເຮົາສາມາດທີ່ຈະນໍາໃຊ້ --with-lib-path configure switch to control ldເສັ້ນທາງຄົ້ນຫາຫ້ອງສະຫມຸດຂອງ.
ສໍາລັບການຜ່ານທີສອງຂອງ GCC, ແຫຼ່ງຂໍ້ມູນຂອງມັນຍັງຕ້ອງໄດ້ຮັບການແກ້ໄຂເພື່ອບອກ GCC ໃຫ້ໃຊ້ຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວໃຫມ່. ການບໍ່ເຮັດແນວນັ້ນຈະສົ່ງຜົນໃຫ້ໂຄງການ GCC ຕົວເອງມີຊື່ຂອງຕົວເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວຈາກລະບົບເຈົ້າພາບ. / lib ໄດເລກະທໍລີທີ່ຝັງຢູ່ໃນພວກມັນ, ເຊິ່ງຈະທໍາລາຍເປົ້າຫມາຍຂອງການຫນີຈາກເຈົ້າພາບ. ຈາກຈຸດນີ້ເປັນຕົ້ນໄປ, ລະບົບຕ່ອງໂສ້ເຄື່ອງມືຫຼັກແມ່ນຕົນເອງມີ ແລະເປັນເຈົ້າພາບ. ສ່ວນທີ່ຍັງເຫຼືອຂອງບົດທີ 5 ທັງໝົດແມ່ນສ້າງຂຶ້ນຕໍ່ກັບ Glibc ໃໝ່ / ເຄື່ອງມື.
ເມື່ອເຂົ້າໄປໃນສະພາບແວດລ້ອມ chroot ໃນບົດທີ 6, ຊຸດທີ່ສໍາຄັນທໍາອິດທີ່ຈະຕິດຕັ້ງແມ່ນ Glibc, ເນື່ອງຈາກລັກສະນະທີ່ພຽງພໍຂອງມັນເອງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ. ເມື່ອ Glibc ນີ້ຖືກຕິດຕັ້ງໃສ່ / usr, ພວກເຮົາຈະປະຕິບັດການປ່ຽນແປງໄວຂອງ toolchain defaults, ແລະຫຼັງຈາກນັ້ນດໍາເນີນການໃນການສ້າງສ່ວນທີ່ເຫຼືອຂອງລະບົບ LFS ເປົ້າຫມາຍ.