Summary: | sys-devel/prelink segfaults and produces strange message | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Augusto Molina <diegoaugustomolina> |
Component: | [OLD] Development | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED INVALID | ||
Severity: | major | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info output
Relevant part of /var/log/emerge.log |
Description
Diego Augusto Molina
2011-07-14 18:06:13 UTC
Created attachment 280089 [details]
emerge --info output
I don't like emerge --info polluting the report
Created attachment 280091 [details]
Relevant part of /var/log/emerge.log
This shows the packages that were emerged. Before this emerge, everything was fine. I made some polling with `emerge' in another term while I was running the `emerge -quDN world'. The last successful one was executed after this line:
1310651225: ::: completed emerge (64 of 94) net-mail/mailbase-1 to /
Hi, I have to say that I'm puzzled in here. I thought that this was a problem related to prelink but I will have to expand the options. I uninstalled prelink and emerge started to do ok but something else happened: I run cryptsetup and it fails the same way prelink used to ("unexpected reloc type in static binarySegmentation Fault"). So I try to imagine that prelink could have installed or modified *something* that `emerge -C' could not remove, or could that be dev-libs/elfutils-0.149, which is pulled in by prelink. Those packages are supicious because they are the only ones that are related to development and elf binaries that were emerged after things had been ok, and then things went wrong. So having this two unmerged cryptsetup fails, I see cryptsetup was compiled statically, then I reemerge it and it works ok! For now I don't need it to be statically linked. Now I want to see what else did I compile statically (which I have control on) so I run: # eix --installed-with-use --compact static [I] dev-libs/glib (2.28.8(2)@07/14/11): The GLib library of C routines [I] dev-libs/libgcrypt (1.4.6@07/14/11): General purpose crypto library based on the code used in GnuPG [I] dev-libs/libgpg-error (1.10@07/14/11): Contains error handling functions used by GnuPG software [I] dev-libs/popt (1.16-r1@07/14/11): Parse Options - Command line parser [I] sys-fs/lvm2 (2.02.73-r1@07/14/11): User-land utilities for LVM2 (device-mapper) software. Found 5 matches. But I have been working with lvm2 and is working ok. Now that I have cryptsetup dynamically linked and working I run: # ldd $(which cryptsetup) linux-vdso.so.1 => (0x00007fff575ff000) libcryptsetup.so.1 => /usr/lib64/libcryptsetup.so.1 (0x00007ff300832000) libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x00007ff300626000) libc.so.6 => /lib64/libc.so.6 (0x00007ff3002a1000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007ff30009c000) libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007ff2ffe76000) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00007ff2ffbfd000) /lib64/ld-linux-x86-64.so.2 (0x00007ff300a48000) libudev.so.0 => /lib64/libudev.so.0 (0x00007ff2ff9ef000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007ff2ff7eb000) Maybe you should rebuild your system with safer LDFLAGS (In reply to comment #4) > Maybe you should rebuild your system with safer LDFLAGS You know, that's exactly the kind of solution I didn't want (I didn't want to recompile the whole thing) but you were right hehe. I deleted the LDFLAGS in /etc/make.conf so that I use the default ones now. To check the problem, I also deleted the 'dynamic' USE flag so that cryptsetup links statically and now it works. Thanks, and I don't think this is a bug really then, it's more a consequence of playing around with LDFLAGS worldwide so I close this as RESOLVED INVALID. |