| View previous topic :: View next topic |
| Author |
Message |
melts
n00b
Joined: 21 Feb 2004
Posts: 53
|
 Posted: Thu Feb 27, 2014 8:53 am Post subject: libpcre and ld |
 |
|
SO, i've had this happen before, and it took me a bit to fix, but ended up doing something dodgy like I have this time
The issue is I don't understand the problem. So I want to see why the file i see isn't just a symbolic link to /lib64 anyway, and why its not working
Here's a copy of what I did to check and fix;
| Code: | melchior tmp # grep --help
grep: error while loading shared libraries: /usr/lib64/libpcre.so.0: invalid ELF header
melchior tmp # ls -alh /usr/lib64/libpcre*
-rwxr-xr-x 1 root root 526 Feb 26 17:00 /usr/lib64/libpcre.so
lrwxrwxrwx 1 root root 10 Jul 1 2012 /usr/lib64/libpcre.so.0 -> libpcre.so
-rwxr-xr-x 1 root root 526 Feb 25 2013 /usr/lib64/libpcre.so.old
lrwxrwxrwx 1 root root 19 Feb 26 17:00 /usr/lib64/libpcrecpp.so -> libpcrecpp.so.0.0.0
lrwxrwxrwx 1 root root 19 Feb 26 17:00 /usr/lib64/libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
-rwxr-xr-x 1 root root 35K Feb 26 17:00 /usr/lib64/libpcrecpp.so.0.0.0
lrwxrwxrwx 1 root root 21 Feb 26 17:00 /usr/lib64/libpcreposix.so -> libpcreposix.so.0.0.2
lrwxrwxrwx 1 root root 21 Feb 26 17:00 /usr/lib64/libpcreposix.so.0 -> libpcreposix.so.0.0.2
-rwxr-xr-x 1 root root 10K Feb 26 17:00 /usr/lib64/libpcreposix.so.0.0.2
melchior tmp # cat /usr/lib64/libpcre.so.0
/* GNU ld script
Since Gentoo has critical dynamic libraries in /lib, and the static versions
in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
run into linking problems. This "fake" dynamic lib is a linker script that
redirects the linker to the real lib. And yes, this works in the cross-
compiling scenario as the sysroot-ed linker will prepend the real path.
See bug http://bugs.gentoo.org/4411 for more info.
*/
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/libpcre.so.1 )
melchior tmp # ls -alh /lib64/libpcre*
-rwxr-xr-x 1 root root 299K Jul 10 2012 /lib64/libpcre.so.0.0
-rwxr-xr-x 1 root root 182K Feb 24 2013 /lib64/libpcre.so.0.0.0
-rwxr-xr-x 1 root root 182K Jul 1 2012 /lib64/libpcre.so.0.0.1
-rwxr-xr-x 1 root root 182K Feb 24 2013 /lib64/libpcre.so.0.old
lrwxrwxrwx 1 root root 16 Feb 26 17:00 /lib64/libpcre.so.1 -> libpcre.so.1.2.1
-rwxr-xr-x 1 root root 258K Feb 27 16:32 /lib64/libpcre.so.1.2.1
-rwxr-xr-x 1 root root 431K Feb 27 16:32 /lib64/libpcre.so.1.2.1.fkd
melchior tmp # mv /usr/lib64/libpcre.so.0 /usr/lib64/libpcre.so.0.retarded
melchior tmp # cp /lib64/libpcre.so.1.2.1 /usr/lib64/libpcre.so.0
melchior tmp # grep --help
Usage: grep [OPTION]... PATTERN [FILE]...
|
I had already copied /lib64/libpcre.so.1.2.1 from another system, moving my original to /lib64/libpcre.so.1.2.1.fkd but this did not fix it.
Copying over the weird ld script fixes it. I don't know why it gets created or why it breaks everything.
Can anyone shed any light on whats going wrong?
I know its happened to me before (i'm reasonably certain on this server too) and the fix was to overwrite the weird ld linker script.
I had just changed my gcc to 4.7.3, done my /etc/profile and attempted emerge -1 libtool when it started error-ing - I don't quite follow how its related
_________________
=== === === === === ===
doh
=== === === === === === |
|
| Back to top |
|
 |
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Thu Feb 27, 2014 10:54 pm Post subject: |
|
|
...and what was the original problem ?
In most of the cases, those linker scripts aren't a problem. |
|
| Back to top |
|
|
melts
n00b
Joined: 21 Feb 2004
Posts: 53
|
| Posted: Fri Feb 28, 2014 2:13 am Post subject: |
|
|
anything built against the library would not run. ie grep;
| Code: | melchior tmp # grep --help
grep: error while loading shared libraries: /usr/lib64/libpcre.so.0: invalid ELF header |
I don't know why Gentoo uses linker scripts, or why replacing it when the file it points to makes it work. All i did was copy the binary the ld script pointed to over the top of the ld script. To me that should not have worked.
_________________
=== === === === === ===
doh
=== === === === === === |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Feb 28, 2014 2:52 am Post subject: |
|
|
It looks like Gentoo uses linker scripts because: | /usr/lib64/libpcre.so wrote: | Since Gentoo has critical dynamic libraries in /lib, and the static versions
in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
run into linking problems. This "fake" dynamic lib is a linker script that
redirects the linker to the real lib. |
This works fine on every Gentoo system I have ever used. If it does not work for you, we need to understand what you are doing differently. |
|
| Back to top |
|
|
melts
n00b
Joined: 21 Feb 2004
Posts: 53
|
| Posted: Wed Mar 05, 2014 7:37 am Post subject: |
|
|
where would you recommend I start looking to find the issue?
My ld reports;
| Code: |
ld: supported targets: elf64-x86-64 elf32-i386 elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex
ld: supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om
|
and that is what is being requested as OUTPUT_FORMAT. I'm not sure how ld is invoked from the ld script, say at runtime of the binary linked against it.
_________________
=== === === === === ===
doh
=== === === === === === |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Wed Mar 05, 2014 8:02 am Post subject: Re: libpcre and ld |
|
|
| melts wrote: | melchior tmp # ls -alh /usr/lib64/libpcre*
-rwxr-xr-x 1 root root 526 Feb 26 17:00 /usr/lib64/libpcre.so
lrwxrwxrwx 1 root root 10 Jul 1 2012 /usr/lib64/libpcre.so.0 -> libpcre.so
-rwxr-xr-x 1 root root 526 Feb 25 2013 /usr/lib64/libpcre.so.old
lrwxrwxrwx 1 root root 19 Feb 26 17:00 /usr/lib64/libpcrecpp.so -> libpcrecpp.so.0.0.0
lrwxrwxrwx 1 root root 19 Feb 26 17:00 /usr/lib64/libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
-rwxr-xr-x 1 root root 35K Feb 26 17:00 /usr/lib64/libpcrecpp.so.0.0.0
lrwxrwxrwx 1 root root 21 Feb 26 17:00 /usr/lib64/libpcreposix.so -> libpcreposix.so.0.0.2
lrwxrwxrwx 1 root root 21 Feb 26 17:00 /usr/lib64/libpcreposix.so.0 -> libpcreposix.so.0.0.2
-rwxr-xr-x 1 root root 10K Feb 26 17:00 /usr/lib64/libpcreposix.so.0.0.2 |
You can tell by the dates what is happening; in early 2013 an .old file has been made, in mid 2012 you might have done something that causes this symlink to have been made.
| TomWij wrote: | $ ls -1 /usr/lib64/libpcre.so*
/usr/lib64/libpcre.so |
As you can see, I don't have that file; it thus kind of seems to have somehow stuck on your system.
| TomWij wrote: | $ grep -r --include='CONTENTS' libpcre.so /var/db/pkg/
/var/db/pkg/app-emulation/emul-linux-x86-baselibs-20131008-r12/CONTENTS:obj /lib32/libpcre.so.1.2.1 e051d598025bdb93e3dc36bcff697e16 1381174481
/var/db/pkg/app-emulation/emul-linux-x86-baselibs-20131008-r12/CONTENTS:sym /lib32/libpcre.so.1 -> libpcre.so.1.2.1 1381262290
/var/db/pkg/app-emulation/emul-linux-x86-baselibs-20131008-r12/CONTENTS:obj /usr/lib32/libpcre.so e2ac9446a9f86506f5b82b30c0e73893 1381174480
/var/db/pkg/dev-libs/libpcre-8.34/CONTENTS:obj /usr/lib64/libpcre.so 953e80a846387f7a0f185adddfff0790 1387313007
/var/db/pkg/dev-libs/libpcre-8.34/CONTENTS:obj /usr/lib/debug/lib64/libpcre.so.1.2.2.debug 6205b1559a7fe303b32e948c17b7c221 1387313008
/var/db/pkg/dev-libs/libpcre-8.34/CONTENTS:obj /lib64/libpcre.so.1.2.2 922116deb8b8a5cd822a6606001016d5 1387313008
/var/db/pkg/dev-libs/libpcre-8.34/CONTENTS:sym /lib64/libpcre.so.1 -> libpcre.so.1.2.2 1387313019 |
As you can see, you can do a grep like above to see if it was installed through a Portage package; it appears to not be the case, so, in my case I could remove it. I suggest you do the same grep and see if it is listed; if not, it is a file that got stuck behind that I suggest you to remove it. |
|
| Back to top |
|
|
|
Portage & Programming
