ugh, i'd forgotten about this issue on the lists. but it seems to only be hitting us when building things statically. to reproduce, build coreutils with USE=static. see random apps fail with this like so: /usr/lib64/portage/bin/ebuild.sh: line 2199: 15866 Aborted (core dumped) chown portage:portage "$T/environment" &>/dev/null or: $ ls -l / ls: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed.
I have encountered this bug as well. So far it hits at least "/bin/ls", "/bin/chown", "/usr/bin/id" and "/usr/bin/stat" which may be involved in "ebuild"ing various packages (thus causing those packages to fail). Replacing the static versions of these programs with old dynamic library versions works around the problem but it is highly undesriable to go ebuilding upgrades and discover coreutils programs that fail one by one. I have a host of other programs built in "static" mode (e.g. /sbin/shutdown, /sbin/runlevel and most importantly /sbin/init) -- so I don't even known if it is possible to reboot my system!!! Recompiling coreutils (w/static) *after* upgrading to glibc-2.12.1 does *not* solve the problem. It looks, at least for ls, that the problem may involve static buffers in the getpwuid library functions.
Created attachment 243167 [details] GDB trace of ls when error is raised. Looks like the problem arises with the getpwuid (getpwuid_r()) call. This call can return an error -- which would be a far better solution (at least for ls) than aborting.
ive posted an update to the upstream thread as to the source of the problem. bottom line: any static apps that use nss functions (which means anything that needs to look up users or groups) will hit this assert.
With respect to comment #3, that doesn't help much. There are those of us who have promoted and compiled apps (binutils, init-utils, nfs-utils, etc) which are and should be "static" (it takes up a non-trivial amount of disk space on the root partition to store and execute such static images). I.e. there should never be a case in which changing the library destroys the functionality of the program (system). That is the fundamental basis of a "reliable" system. Now I am left with a system with an upgraded library which will likely be unable to "reboot" -- because /sbin/init is "static", Thus Gentoo and associated GNU providers have created a situation where quote, unquote "static" images are not in fact "static" (i.e. the programs images themselves contain all information necessary to execute properly), If there are people who distrust ".dlls" or ".sos" because they can become corrupted or fail to be read from the disk, etc. then there are people who really want "static" images. I.e. If I envoke "vi" I get "vi" and it will always work no matter what the state of the libraries (if it is built as a static image). The folks at Gentoo need to pay more significant attention to this -- in theory I've got a system which will not reboot. Because I built things as "static" images which it seems to turn out are not so "static" in reality. Thank god I created an alternate Ubuntu boot partition so Gentoo cannot completely create a DOA environment. If part of the valid upgrade path for Gentoo (including glibs which break significant parts of the system) then one really needs to have some external process which approves/validates such upgrades. Because as it sits now -- it does not work. (As witnessed due to the fact that I don't dare to reboot my system.)
no one said this bug was fixed or that static binaries crashing was expected behavior or that static binaries arent supported. nor is this bug specific to Gentoo. we merely hit it before Ubuntu. you're basically complaining about behavior that the glibc maintainers themselves dont care about. if you want a stable system, then use stable. ~arch will see ups & downs everyday. there never was and there never will be a guarantee of anything else.
Created attachment 243479 [details, diff] glibc-2.12-static-glro-init.patch this should fix glibc, but all static apps linked against older glibc will need to be relinked
I had this problem with zsh (static). Applying the patch and rebuilding glibc and zsh (as well as the other static packages) seems to have solved that problem. However, I now get: zsh: illegal hardware instruction zsh
Please append to this bug when the patch makes it into the distribution tree. It is difficult enough to try and follow the bleeding edge without having to stick patches on top of that. It would appear from "equery hasuse static" that this glibc upgrade may require my rebuilding up to 56 packages on the system. It definitely causes openssh (sshd) problems which I have rebuilt non-static. Now, I'm "old-old" school here. Once upon a time (circa 1974-1987) when UNIX was alive and well a "static" link really was indeed static. I.e. to corrupt an executable one had to corrupt the blocks within that executable. Which tends to be why we "old folks" like static links -- you can't disable an entire system by corrupting a library. That appears to no longer be the case. Since upgrading glibc appears to have hosed every "static" program (or any static program which I have on the disk (Or at least any which attempts to access the passwd functions???) . So the question may remain, and I realize this may not be a Gentoo problem but an upstream problem, why in this day and age does glibc not have robust, real and reliable "static" link capabilities? I.e. upgrading glibc which is likely shared across some 6800+ programs in /bin & /usr/bin will break the core utilities needed for my system to work? And I would point out that I don't believe Gentoo "as distributed" (or Ubuntu) is immune to this problem. Remove /lib/libc-X.so and the whole system crumbles. Which is precisely why people would take the time (and disk space) to build "static" systems.
bugs get closed when they're integrated into the tree. i havent merged the patch yet as i'm waiting for upstream feedback and i'm not going to force a bunch of -r1/-r2/-r3 bumps on people. upstream glibc does not care about static linking. they have many times stated bluntly "static linking is not supported". you will see this behavior on every single distro out there that moves from <glibc-2.12 to >=glibc-2.12.
glibc-2.12.1-r1 includes this fix, and a pkg_setup check for people who try to emerge with sys-apps/coreutils[static]
Good try. Given that coreutils and (install) had to be installed dynamic on top of 12.2.1 (and one can't "deinstall" it [Downgrading glbc fails due to Gentoo restrictions -- in spite of the fact that it will in most probably work).] One should *always* be able to both install and both deinstall upgrades. Nothing should be beyond revocation. And that may mean that beta-testers have to both test installation and deistallation. So be it. The bottom line is that the upgrade of 2.12.1 failed for individuals who had a significanlt "intstalled" staic library presence. So the Gentoo upgrade broke their systems. The background is that it looks like there was an attempt to fix some of the memory allocation problems (mkdtemp, etc.) which failed with repsecct to the 2.12.1 upgrade. -- there should never be a dependecy on a critical glibc/gnome library upon a static library -- exchanging libraries should not break systems. What if we had a critical government system dependent upon a gnome library and if it failed (due to a failure in a glibc library) the whole architecture fell apart? What part of the infrastructure are you comfortable bringing down because your libraries failed? And do you know what fraction of the government depends upon your infrastructure?
the glibc downgrade sanity check can easily be bypassed by doing: ROOT="/../" emerge glibc other than that, no, i'm not dropping the downgrade sanity check. the vast majority of the time it is correct as it is people who dont understand the repercussions trying to downgrade (and then break their systems). as for your gnome/glibc bits, i havent a clue what you're talking about. as for stability in ~arch, you've already had that explained. as for static linking not being as stable as you like, you've had that explained too. complaining here wont change a thing since this isnt specific to Gentoo at all, although complaining upstream most likely wont change a thing either since the maintainer has made his decision quite clear. so unless you have actual feedback for improving the glibc ebuild and/or upgrade process, please refrain from basically ranting. bugzilla isnt the place for such things.
hi I am using commercial program which I was not using for a while. after some weeks I did want to run that program but now I am getting following message on console. NG_LM_status.x: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed. Segmentation fault also checking this ldd my_program but getting this message: not a dynamic executable please, how can I fix it? thanks
sorry, but chances are you're screwed. install an old glibc into a special dir and have your app run against that. you can read info here: http://dev.gentoo.org/~vapier/old-broken-errno-apps (the problem isnt the same, but the solution is)
*** Bug 368603 has been marked as a duplicate of this bug. ***
this should be fixed in glibc-2.15+ in a backwards compatible way
