On Tue, Apr 14, 2020 at 12:13:21PM -0400, Olivier Langlois wrote: > Hi Xi, > > On Tue, 2020-04-14 at 10:03 +0800, Xi Ruoyao wrote: > > On 2020-04-13 20:41 -0400， Olivier Langlois wrote:
[ just a few minor comments ] > > > > I think something like -L/home/juicingf/dev/glibc- > > install/home/juicingf/lib > > -I/home/juicingf/dev/glibc-install/home/juicingf/include is also > > needed. Or it > > will be mixing up the new dynamic linker and old libraries. > > Of course but pointing the linker to your lib directory is baby > knowledge. I omitted that detail because I assumed that everyone here > know. I just pointed out that I took care of the dynamic linker as this > is the #1 reason why attempts to do that is failing. I have seen > another approach with binutils elfedit too in the meantime.. > You are clearly in advance of many people here in whatever it is you are doing (I've failed to follow a lot of this, and since upgrading a running old distro to my own new glibc is not something I would even dream of doing I mostly have no comments. Assuming that everyone on LFS-support has your own level of knowledge about things which are at best tangential to LFS helps nobody. > > > > > > As an extra safety measure, I'm going to test my rpms on a QEMU > > > CentOs > > > VM first. After fixing a bunch of rpms dependency issues, my glibc > > > rpm > > > finally got installed on my VM, and as soon as the symlinks got > > > replaced, every single new executed program started to all > > > terminate > > > with SIGSEGV (11). > > > > > > Oh boy, I'm so glad to have tested my rpms on a VM before doing it > > > on > > > the real system but now, I would like to have some help to find a > > > solution to my SIGSEGV issue. > > > > > > Again, I have few ideas of things to try out: > > > 1. I'm guilty of having built glibc with -march=native > > > -mtune=native > > > which translate to sandybridge. My QEMU host is a skylake > > > processor. > > > Maybe despite using QEMU switch (-cpu SandyBridge), some unique > > > SandyBridge instructions aren't well emulated by QEMU. I'm going to > > > rule out this possibility by rebuilding glibc without those evil > > > switches and report back my findings if someone in the list tells > > > that > > > he would be interested to know. > > > > I don't think so. It should cause SIGILL instead of SIGSEGV. > > If it was happening to a real machine, what you say makes sense and > this is what I would expect as well. This comment did make me doubt > that trying out recompiling glibc without '-march=native -mtune=native' > would do anything. > > but I did nonetheless and it did work! No more SEGV. Perhaps the QEMU > machine emulation isn't 100% accurate. > That seems very possible, particularly if your qemu is old. > This has been a big lesson. I'll think twice from now on before > compiling a system library with those switches. Using them to build a > program is ok. If it fails down the road, no big deal. but a system > library, especially glibc, it is asking for trouble. Maybe if it is > your computer, you can get away with it. > > My production CentOS is also a VM. My SandyBridge build was working > fine on that machine but the VM could be moved on a new machine anytime > without prior notice and instantly become bricked as it did happen on > my test VM. > > That is my big lesson here. Dont' use those evil switches... > > On real hardware, -march=native -mtune=native generally provides speed-ups. There has been case where (from memory) an old version of gcc with newer hardware misidentified what it could use and did not use some options it could have used - in that case, specifying a slightly earlier machine type was faster. For real hardware, the possible problem is that you may not be able to move the binaries to a newer machine. On my own machines I definitely use -march=native with glibc (and with almost everything) to try to recover some of the loss from hardening the build. But on a VM ? Even if the toolchain agrees that the current VM is a SandyBridge, who knows what will turn up if hte VM is migrated. > > > > > IOW, if I want to perform a glibc system upgrade, should I proceed > > > mandatorily to a binutils/gcc-libs system upgrade first? > > > > Don't do that. If you really need such an upgrade, upgrade your > > distribution. > > Porting old applications onto new distribution seems time wasting, > > but messing > > around system glibc (and cheating the distribution package manager) > > will waste > > more time. Trust me. > > Well, I disagree on that last point with you. I would place my endeavor > in the same category than going through LFS. Maybe I didn't expect all > the bumps that I did encounter and I didn't expect the journey to be as > long as it did. But it has been extremely educational. I got much > better insight about how Linux work as result. And ultimately, I got > the upperhand over my system by configuring it the way that I wanted it > to be. > I would place your endeavours on a par with the early years of LFS, where the basic HOWTO was first sketched out and people then often managed to build systems which booted. Eventually, after the aggravations of the LFS-4 period where some people got build problems that others didn't, we moved to adding tests and trying to get a purer build. What you seem to be doing has very little relevance to most people who build LFS. I'm sure it will continue to be educational if you continue with it, but I expect it to continue to cause you pain. Google finds references for upgrading from Centos 6, but an alternative would be to do a fresh install of the newer system. ĸen -- The beauty of reading a page of de Selby is that it leads one inescapably to the conclusion that one is not, of all nincompoops, the greatest. -- du Garbandier -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
