The error message is: Inconsistency detected by ld.so: dynamic-link.h: 161: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed! I diagnosed and reported this bug to the glibc people a while ago, maybe it'll be fixed in the next glibc version. 2.3.2-r1 however still has this problem. Reproducible: Always Steps to Reproduce: 1. export LD_RUN_PATH=/does/not/matter 2. emerge -u glibc 3. Actual Results: Inconsistency detected by ld.so: dynamic-link.h: 161: elf_get_dynamic_info: Assertion `info[15] == ((void *)0)' failed! make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/buildhere/sunrpc/rpcsvc/bootparam_prot.stmp] Error 127 make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2/sunrpc' make[1]: *** [sunrpc/others] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r1/work/glibc-2.3.2' make: *** [all] Error 2 Expected Results: compile through ;)
This bug is still not fixed in glibc-2.3.2-r7. Why? It's trivial! Just unset LD_RUN_PATH before calling configure. Another two hours of my time wasted with this glibc bullshit. Please fix this now!
Ah, I see the problem now. The env variable LD_RUN_PATH affects ld, which causes strange linking ... The real problem is where LD_RUN_PATH is set, as it would effect all compiling.. Find this and that is the true source of the problem! There are many env variables which could zap any ebuild, but there are rare enough not to unset them all; this could be one of them.
i'd suggest making this a variable users arent allowed to over ride in the portage environment
Oh come on, _yet_ another glibc version, 2.3.2-r9, and this bug is _still_ not fixed? What is the matter with you people? Just edit dynamic-link.h, line 184, and comment that line out. Is it that difficult? I don't get it. This is about the eighth hour I have wasted watching Gentoo build glibc and then fail because of this bug. If you don't want to fix that bug in the glibc sources, please at least unset LD_RUN_PATH in the ebuild. I didn't think doing this was so immensely difficult! I reported this in April, that's over half a year ago!
can you tell me the reason you are explicitly setting LD_RUN_PATH you may ask yourself why this bug has been "hanging" around in glibc and bugzilla so long - i would not comment on that other than to say that it is "extraordinary" to set those kinds of environment variables. but on the other hand you are right to get it fixed because it adds up to some unwanted behaviour. thanks, Alex
I am setting LD_RUN_PATH explicitly because it is in my standard shell environment. This is a development box, not just a Gentoo environment. I am setting LD_RUN_PATH to point to all my projects so the binaries will find their shared libraries without me having to list 30 more directories in ld.so.conf.
could there be any unforeseen side effects from unsetting the LD_RUN_PATH in the glibc ebuild?
Babysitting is not portage's primary mode of operation. Please fix your environment as it obviously has some issues if it's breaking libc. Felix, please quit being so brash, as this is obviously such a massive and widespread problem that you are the only one complaining semi-anually. I'm not touching this until I get a concensus on it. I'm really not concerned about this, and don't intend to remove it globally as I've known a couple of users that actually employed this as a feature. If anyone cares to see something happen, feel free to talk to people and have them comment on this.
Excuse me? I describe a clear bug in portage, I tell you how to fix it, there are no counterindications, and now you refuse to fix it on the grounds that noone else complained?! Can I see your superior please? This kind of behaviour might be tolerable for Debian. It is not for Gentoo. If this is how Gentoo handles bug reports, I'm outta here. I am reopening this mainly because you say "I've known a couple of users that actually employed this as a feature". I call your bluff. Please explain how triggering an unnecessary assertion in the system dynamic linker (which will break any and every program in the system) can be construed as a feature. I'm actually very curious. I have been bullshitted before by other distributions, but calling this a feature, that takes the cake. And I thought I finally found a distribution that actually tried to fix bugs people report. Sheesh. LD_RUN_PATH is neither undocumented nor particularly obscure. man ld documents it. I use it. Your system component breaks. Fix it. How can you even discuss this? Uncommenting that one stupid line in glibc would have taken you like 10 minutes, much less than posting this insulting bugzilla entry here.
Felix, please don't be so harsh with this. The problem here is that you are running a non-standard environment, and the effects of making the change are, at least to some of us, unknown for other users and other packages. Maybe Azarah has a comment. In the meantime, I'll request that you try and keep your temper under control.
EVERYONE has a non-standard environment! That is the whole IDEA behind Gentoo! If I wanted a non-configurable restricting "standard" corset, I'd be using MacOS. Look, I understand if you are cautious. I understand if you want to take a week or two to look for side effects (there are none). But this bug has been open for almost a year now. Even Microsoft fixes their bugs faster than that.
Is this only about the glibc ebuild or unsetting the variable for portage in general? If it's the former then it's not dev-portage territory anyway. (Note: before you accuse someone make sure you are not misunderstanding him)
You said you sent this upstream to the glibc people, do you know if they're gonna include this fix in the next release?, if so, you might try the glibc-2.3.3_pre20040207 ebuild and see if it's fixed in there, or try glibc cvs and see if it's fixed. If it is, then this bug could be fixed with the release of glibc-2.3.3. Otherwise, it is an issue that needs to be checked. glibc isn't a trivial package to just go adding tweaks/fixes reported by only one person thus far. While the age of this bug isn't exactly something to happy of, you admit you do have a rather non-standard operating environment (out of the normal gentoo environment, which itself can vary depending on installation), so it currently looks like you're the only one experiencing this issue. On the other hand, maybe a more recent glibc-2.3.3_pre200403* ebuild can be cooked up when Azarah gets some free time (he's been rather busy lately), and this fix can be tossed into it for testing, since it'd be an experimental ebuild anyways.
I recommended removing the superfluous assertion, because that will fix the problem without touching anything else. I did not assign this to dev-portage. I have no idea why the glibc people have not done anything or if they have done anything in the most recent snapshot. And, to be honest, I am not comfortable installing a beta glibc snapshot on my development machine. glibc has broken binary compatibility before, I do not want to compromise my binaries. It was aeons ago that I reported this to the glibc people and never heard anything back from them. They probably have their reasons to ignore bug reports. I did not expect anything else (why would they listen to me, I am bashing them all the time and even wrote my own libc to get rid of glibc where I can). I do expect Gentoo to fix bugs that are reported to them even if upstream is not able or not willing to fix a bug. Gentoo does this all the time to packages all over the portage tree. I fail to see why it can not or should not be done here. About the question whether to unset LD_RUN_PATH or not globally in portage: how can you say on one hand that my environment is non-standard because I set LD_RUN_PATH and on the other hand say you don't know if unsetting would break anything? I don't get it. Either you say I am not supposed to set it (and then go ahead and unset it), or I am supposed to be able to set it, then please remove the assertion in glibc. Either way, this is a bug. Please fix it.
Seemant is probably the superior you'd want to talk to if you feel the need. Perhaps I am confusing LD_RUN_PATH with LD_PRELOAD or some other linker variable, but the main point is still that this is something that hasn't ever come up (as far as we're aware) for anyone except you. If you can point out a bug on gcc's tracker where they have accepted the issue and a fix, I'm sure someone can see if it's worth our time applying such a patch to a critical package. I must also be confused about how this works for your regular development work but fails for glibc. Base-system: care to take ownership here?
I don't see any patches attached to this bug. Please attach/propose one that clearly shows the behavior you desire.
Created attachment 33537 [details, diff] glibc CVS HEAD bug fix patch
Travis Tilley or Peter Mazinger, can you evaluate this please and take care of adding it to recent glibc versions? Thanks in advance, Alex
i'm sorry, i dont know why that line was added so i am not about to just comment it out. if you want that done, take it up with the upstream devs. however, i dont see much harm in unsetting that environment variable. it's not present on any normal system and should only have an effect on this one user. fixed in all glibc ebuilds... enjoy.
