Hi Xi, On Tue, 2020-04-14 at 10:03 +0800, Xi Ruoyao wrote: > On 2020-04-13 20:41 -0400， Olivier Langlois wrote: > > Hi, > > > > TLDR: Does any LFS user/expert knows if glibc libraries needs any > > binutils/gcc so libs to work correctly or they are essentially just > > needed for the build? > > > > Here is the full background story: > > > > I have this project which is not a full LFS system but share quite > > some > > similarities. > > > > I want to upgrade glibc to a recent version on an old CentOS 6 > > system > > (kernel v2.6.32, binutils 2.20, glibc 2.12, gcc 4.4.7). Because > > everything is so old on that system that it practically means > > almost > > going through the whole LFS chapter 5 to succeed. I did read your > > book > > in an attempt to find the answer for the most recent issue that I > > did > > encounter. > > > > Because, I have already bricked a system by trying to manually > > upgrade > > glibc, I wanted to keep everything private into my home directory. > > I > > have learned the hard way trying to do the following: > > > > 1. Copy new glibc libs into system dirs > > 2. remove old symlinks > > 3. Create new symlinks > > > > Anyone who played a bit with LFS knows where the plan stopped > > working. > > > > On first attempt, I did try to install glibc 2.31. Once done and it > > was > > time to run a hello world program using it, I got the following > > error: > > FATAL: Kernel too old. > > Why not upgrade the entire distribution?
CentOS 6 is officially supported until November this year. I'm planning to migrate to a newer dist probably early this fall but right or wrong, I see that task more daunting than what I'm currently doing... > > > I have learned the last glibc version supporting my kernel is 2.25. > > So > > I download 2.25 recompile and install it locally in my home > > directory. > > This time it works: > > > > # /lib64/libc.so.6 > > GNU C Library stable release version 2.12, by Roland McGrath et al. > > Copyright (C) 2010 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. > > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > > PARTICULAR PURPOSE. > > Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-23). > > Compiled on a Linux 2.6.32 system on 2019-04-09. > > Available extensions: > > The C stubs add-on version 2.1.2. > > crypt add-on version 2.1 by Michael Glad and others > > GNU Libidn by Simon Josefsson > > Native POSIX Threads Library by Ulrich Drepper et al > > BIND-8.2.3-T5B > > RT using linux kernel aio > > libc ABIs: UNIQUE IFUNC > > For bug reporting instructions, please see: > > < > > http://www.gnu.org/software/libc/bugs.html > > > > > > > to: > > > > # /home/juicingf/dev/glibc-install/home/juicingf/lib/libc.so.6 > > GNU C Library (GNU libc) stable release version 2.25, by Roland > > McGrath > > et al. > > Copyright (C) 2017 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. > > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > > PARTICULAR PURPOSE. > > Compiled by GNU CC version 9.3.0. > > Available extensions: > > crypt add-on version 2.1 by Michael Glad and others > > GNU Libidn by Simon Josefsson > > Native POSIX Threads Library by Ulrich Drepper et al > > BIND-8.2.3-T5B > > libc ABIs: UNIQUE IFUNC > > For bug reporting instructions, please see: > > < > > http://www.gnu.org/software/libc/bugs.html > > >;;;. > > > > I try to build a more substantial program using my private glibc by > > using the following linker switch: > > -Wl,--dynamic-linker=/home/juicingf/dev/glibc- > > install/home/juicingf/lib/ld-linux-x86-64.so.2 > > that I got from: > > https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host > > > > > > It works fine except when my program exit the main function, I get > > this > > error: > > relocation error: /home/juicingf/dev/glibc- > > install/home/juicingf/lib/libc.so.6: symbol > > _dl_find_dso_for_object, > > version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with > > link time reference > > 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.. Header files mix-up isn't impossible. Recompile everything with the 2.25 header files once I succeed in installing it will clear out that possibility and is in my TODO list. but I was under the impression that glibc was working very hard to maintain a binary backward compatibility and programs compiled with older header files should work fine. I will find out. Instead of using the 2.25 from the official tar files repository, I did fetch the 2.25 master branch from glibc git that I just found out was existing. Can you believe it that 2.25 still receive important bug fixes still today? Last commit was something like few hours ago! I'm not ruling out the header file mismatch glitch but my guts points me toward some possible bug in the code that could have been fixed since the release. We will see. This issue is still ongoing. > > > This is not such a big deal except that ideally I would prefer not > > to > > have this issue at all. I did search a bit the origin of the error > > and > > I have found the source: > > stdlib/cxa_thread_atexit_impl.c > > > > If anyone has a clue, why I am getting that, I would be interested > > in > > hearing your ideas. > > > > I formulate 2 possible explanations: > > 1. gcc compile script option --enable-__cxa_atexit was set. I > > picked > > this option from ArchLinux gcc PKGBUILD file. It seems important to > > me > > since I'm doing a lot of C++ > > https://stackoverflow.com/questions/42912038/what-is-the-difference-between-cxa-atexit-and-atexit > > > > On Linux --enable_cxa_atexit is enabled by default. Ok thx, I didn't know. > > > 2. I have reached the limit of what is possible to achieve without > > a > > system real glibc upgrade. > > If it's true you should really upgrade to a new CentOS version. What I was talking about here was the investigation options for this problem. This is just speculation. The error message is just really annoying me. I'm so invested in finding a solution that doing the system update would eliminate one possible source of the issue. I'm mixing system libraries with some other libraries and I'm starting to get weird dynamic loading issues. I would rather prefer having every components most of the needed libs from a single location. In fact, I did recompile one library (libmariadb) just because I did stumble into one weird linking problem. upgrading glibc seems like the wiser choice than putting my hand further into the dependency hell pandora box. > > > Therefore, based on my previous glibc upgrade attempt where I have > > learned that in order to not brick the system, you have to replace > > the > > symlinks atomically from a single program that has already loaded > > glibc > > before changing the symlinks. > > > > So, I have learned everything about creating a rpm package, how to > > use > > the rpmrebuild tool and I created rpms with my glibc 2.25 files to > > replace the ones on my system. > > > > 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. 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... > > > 2. glibc has some runtime dependency that I am not aware of. I did > > notice that bintutils and gcc were generating few so files. > > > > Does any LFS user/expert knows if glibc libraries needs any > > binutils/gcc libs to work correctly or they are essentially just > > needed > > for the build? > > No, they are not needed by most programs. I did an experiment: > > $ sudo unshare -m > # mount --bind /dev/null /usr/lib/libgcc_s.so.1 > # ls > (ls works fine) > # gcc hw.c > # ./a.out > Hello world. thx. it is good to know > > > 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. and IMHO, this is exactely what LFS is all about! Take care and thx for your reply! Olivier -- 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
