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? > 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. > 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. > 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. > 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. > 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. > 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. -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- 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
