Le 30/12/2019 à 18:01, Christopher Gregory via blfs-support a écrit : > > >> Sent: Tuesday, December 31, 2019 at 3:30 AM >> From: "Chris Gorman via blfs-support" >> <[email protected]> >> To: "Leandro Nini" <[email protected]>, "BLFS Support List" >> <[email protected]> >> Cc: "Chris Gorman" <[email protected]> >> Subject: Re: [blfs-support] fixing broken debug libraries on a blfs system >> >> Hi Leandro, >> >> Thanks for the tip. I may try it out, but I think I will try >> Christopher's suggestion and use ALFS to build my system. Just have >> to do some thinking about how to implement it. >> >> Thanks again, >> >> Chris >> >> On Mon, Dec 30, 2019 at 5:21 AM Leandro Nini via blfs-support >> <[email protected]> wrote: >>> >>>>>> Sent: Monday, December 30, 2019 at 12:42 PM > > From: "Chris Gorman via >>>>>> blfs-support" > > To: [email protected] > > Cc: >>>>>> "Chris Gorman" > > Subject: [blfs-support] fixing broken debug libraries >>>>>> on a blfs system > > > > Hello, > > > > In my haste to get things going, >>>>>> I believe I ran the strip command > > twice for libraries built by >>>>>> glibc-2.30 during my LFS build. This has > > as far as I can tell broken >>>>>> the .dbg libraries. (Each is now smaller > > than its respective >>>>>> stripped library.) I am wondering if anyone has > > experience building >>>>>> glibc-2.30 on a blfs system, and if so what the > > build algorithm >>>>>> would be? > > > > Should I be able to follow the LFS chroot instructions >>>>>> with > > > > CC="gcc -ffile-prefix-map=/usr" > > > > instead of > > > > >>>>>> CC="gcc -ffile-prefix-map=/tools=/usr" > > > > on my BLFS system? > > > >>>>>> > Should I rebuild the /tools and then use them to build glibc-2.30 > > >>>>>> under a chroot environment with my host operating system again? > > > > >>>>>> Or should I ignore the missing debug symbols and move on? > > > > Hoping >>>>>> someone can help. > > > > Chris > > -- > > >>>>>> http://lists.linuxfromscratch.org/listinfo/blfs-support > > FAQ: >>>>>> http://www.linuxfromscratch.org/blfs/faq.html > > Unsubscribe: See the >>>>>> above information page > > > > Hello, > > I would suggest that you chalk >>>>>> your lfs build up to a learning experience, and re-do it from scratch. >>>>>> You can speed up the building time, by using jhalfs to build the >>>>>> complete system. You have the option of speeding things up even further >>>>>> if you do not wish to run the test suites. > > That way you would get a >>>>>> working base lfs to base your blfs build on. It is not generally a good >>>>>> idea to rebuild glibc on an already installed lfs system, as there is >>>>>> normally not a package manager to work with, and the rebuild could cause >>>>>> you more problems down the track. > > Regards, > > Christopher. > -- > >>>>>> http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: >>>>>> http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the >>>>>> above information page > > Hello, if you've already deleted the /tools >>>>>> directory you won't need the -ffile-prefix-map option. The only thing >>>>>> you should take care of when updating glibc is the install step; instead >>>>>> of issuing the "make install" command you should use an install root as >>>>>> follows to avoid trouble: make install_root=/tmp/glibc install cd >>>>>> /tmp/glibc cp -a --remove-destination . / However always be careful when >>>>>> touching the core components of the toolchain as it's easy to make the >>>>>> system unusable. Kind Regards, Leandro -- >>> http://lists.linuxfromscratch.org/listinfo/blfs-support >>> FAQ: http://www.linuxfromscratch.org/blfs/faq.html >>> Unsubscribe: See the above information page >> -- >> http://lists.linuxfromscratch.org/listinfo/blfs-support >> FAQ: http://www.linuxfromscratch.org/blfs/faq.html >> Unsubscribe: See the above information page >> > > Hello, > > A quick guide for using jhalfs: > > mkdir /mnt/build_dir > mount /dev/sdII /mnt/build_dir > > You set your $LFS variable as per normal. > > You need to run jhalfs as a normal user, so you will need to make sure that > the user does own the mounted directory. It has a make file, and it is menu > driven. I would suggest that you stay away from using the optimization > settings ie the make -j5 as I have found with various builds that I get a > race condition for one or more packages that results in the build stopping > until I add that package to the blacklist. Once you do run make a menu, that > was borrowed and adapted from busybox will appear. I always find it easier > to copy the current .config and the /etc/fstab into the /mnt/build_dir and > point, within the jhalf menu to those files. > > That way, if you do have a fully functioning kernel with all of your tuned > drivers etc, then that is what will get built. You also have the option of > building either a sysv or a systemd system. >
In addition, I think that, for recent versions of jhalfs, the user needs to be able to run sudo. Then, there is no need to own the /mnt/build_dir directory. Also, if you want jhalfs to download the package tarballs, you have to set the SRC_ARCHIVE variable (or change it in the menu). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
