unexpected reloc type in static binary

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

Hi all, after making a general system upgrade I've noticed executing emerge (even with no args) prints "unexpected reloc type in static binary". I think this is a glibc issue as this message is printed directly to the terminal: `emerge &> /dev/null' still outputs this annoying thing. I remember oher cases where glibc outputs messages this way. I updated glibc from version 2.11.2-r3 to 2.12.2, both with this USEs: gd glibc-omitfp multilib nls.
Is this serious? should I worry about this or it's a dummy thing?

Thanks for reading!

BradN · Posted: Fri Jul 08, 2011 1:31 am Post subject:

If you're using prelink, you could try undoing that, I tried googling that message and found some stuff about that... not sure if that's actually the issue though.

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

Ok, thanks for that. But it has just gotten scared.

BradN · Posted: Fri Jul 08, 2011 3:42 pm Post subject:

What change did you make?

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

I'm installing a xen dom0, still nothing working on it. I had copied a make.conf for an x86 dom0 I had previously used. I thought I had done all the changes to that file to adapt it to the new environment but I forgot to delete the '-mno-tls-direct-seg-refs' from my CFLAGS, which are also my CXXFLAGS. I know this is no major problem (none at all in fact) but I wanted to start a very clean and fresh install. I don't have much things installed, only the basics. This issue had already been happening before I change CFLAGS and CXXFLAGS. What I hadn't tried before the change is to unprelink the system. So, cronologically, this is what has happened:

system is happy
emerge --sync && emerge -qauDN world
Of course there was a review in this step. Among the most important packages updated: glibc from version 2.11.2-r3 to 2.12.2 (which I think is causing the problem).
Problem appears. All I notice about this problem is that when I run emerge in any manner, I can see it outputs directly into the terminal "unexpected reloc type in static binary". Search about this. Nothing related specifically to this (in my search, I found this message in other contexts). Didn't think it had anything to do with prelink.
I've got `buildpkg' in my FEATURES to be able to use the binaries produced in the domUs I create inside this dom0. I was preparing a stage4 for the domUs to be created. Chrooted into it. I did an `emerge -qek world' (same USEs as dom0, less ebuilds listed in world file) which didn't output the message and after this, emerge did. glibc where also reinstalled in this action.
Change variables in make.conf from this:

Code:

CFLAGS="-O2 -pipe -mno-tls-direct-seg-refs -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

To this:

Code:

CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

And then recompile everything using `emerge -qe world'.
As BradN suggested prelink may be related to this, I try `prelink -au' and then `prelink -afmR', both failing with a segfault after showing the message.
Now I'm scared. This should be producing things soon.

Again, if you need to know something, just ask!

BradN · Posted: Fri Jul 08, 2011 6:04 pm Post subject:

What happens if you start a chroot install and just install prelink in there, then use that prelink binary and libraries to try to un-prelink your main install?

Since obviously it will look for your current system libraries, you'll probably need a way to trick it into using the libraries from the chroot, maybe this can be done by copying all the libraries it uses (find them with ldd) into a directory and then overriding the ld library path (I haven't experimented a lot with that sort of thing).

I hate to say it, but in important installs, it's really a good idea to perform regular full OS backups as well as data to help reduce problem severity in cases like this. A tar command is cheap, spending hours/days rebuilding everything isn't

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

BradN · Posted: Sat Jul 09, 2011 12:53 am Post subject:

Sounds like the kernel then.

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

Look! Brand new server. Brand new system (stage3-amd64-20110609.tar.bz2, July 11th portage) and it's the first time this machine boots on it's own. I had only installed the utterly needed packages to boot and never still hadn't found the message. Prelink is not even considered yet. I made an `emerge -pve world' (with an empty world file because I forgot to modify it. Then it's the same than `emerge -pve system') and in another term started to make an `emerge' once in a while to see what happened. It's funny that I found the other glibc message I know of, but haven't seen in a long while:

BradN · Posted: Thu Jul 14, 2011 3:26 pm Post subject:

Definitely report it, it should be masked at least.

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

Submited

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

This is not closed! Please follow the bug.

BradN · Posted: Fri Jul 15, 2011 5:11 am Post subject:

It's my understanding that after you install prelink, other packages you emerge are automatically prelinked, and uninstalling prelink won't automatically undo it.

Normally this isn't a problem because if the prelinking is invalid it's supposed to fall back to the normal dynamic linking procedures, but something must be going wrong here.

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

Hi, as suggested by Pacho Ramos in the bug, I recompiled everything with safer LDFLAGS (the default ones). It works now. I have to say that I have been using those ones since a couple of years with good results, but I'm betting on stability for now.

BradN · Posted: Fri Jul 15, 2011 4:04 pm Post subject:

Can you tell which ldflag it was that caused the problem? It may still be a bug in prelink (or something else) if it was working like that before but not now.

diegoaugustomolina · n00b Joined: 22 Mar 2010 Posts: 32

BradN · Posted: Fri Jul 15, 2011 11:59 pm Post subject:

Well it's still a bug if prelink is supposed to work with those ldflags - I don't know enough about the specific details. But, if it's a ldflag that interferes with the process in a way that it's not reasonable to support that configuration, I'd guess it's not a bug then.

But perhaps an error/warning would be nice at prelink install time in that case though, seeing that prelink seems to be the main case where that ldflag breaks badly. To me, the whole idea is keeping the next person from running into the same troubleshooting

You may want to open a new bug or edit the subject (if possible) of it to be directly like "prelinked executables crash with LDFLAGS=-whatever" - then perhaps it will get the attention of someone who deals with linker stuff.