Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409121 - pango failed with /lib64/libm.a(k_standard.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libm.a: could not read symbols: Bad value
Summary: pango failed with /lib64/libm.a(k_standard.o): relocation R_X86_64_32S agains...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-21 09:42 UTC by Alessandro Surace
Modified: 2012-03-21 15:32 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
buld.log (build.log,19.38 KB, text/plain)
2012-03-21 09:42 UTC, Alessandro Surace
Details
emerge --info (emerge_info.txt,7.01 KB, text/plain)
2012-03-21 09:43 UTC, Alessandro Surace
Details
environment (environment,110.30 KB, text/plain)
2012-03-21 09:44 UTC, Alessandro Surace
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alessandro Surace 2012-03-21 09:42:47 UTC
Created attachment 306109 [details]
buld.log

Hi,
in my periodically upgrade process I've found a general problem that can be detailed in pango build.

Every time I build I get the error:
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libm.a(k_standard.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libm.a: could not read symbols: Bad value

I've seen ad adopted the solution in http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 without success.

I've tried to rebuild automake and autoconf but nothing change.

At this point I've tried to rebuild glibc but I've find another problem about libunwind.

The problem doesn't happen only with pango but this is the first occurence.
Comment 1 Alessandro Surace 2012-03-21 09:43:30 UTC
Created attachment 306111 [details]
emerge --info
Comment 2 Alessandro Surace 2012-03-21 09:44:20 UTC
Created attachment 306115 [details]
environment
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2012-03-21 09:52:08 UTC
Provide outputs of

$ ls -ld /usr/lib/libm.so* /lib/libm.so*
$ file /lib/libm*.so*
$ ls -ld /lib /lib64 /usr/lib /usr/lib64

In other words, verifying the correct symlinks are in place and libm.so is available and working
Comment 4 Alessandro Surace 2012-03-21 10:58:23 UTC
That is wornderful!

Some day ago I have relocated /usr/lib64 to another filesystem.

All the relative symlinks to /lib64 was failed .

I've recreated all the symlinks and now pango has been build correctly.

Can you explain how do you diagnose the problem from that error!?!

I can't understand.
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2012-03-21 11:02:31 UTC
(In reply to comment #4)
> That is wornderful!
> 
> Some day ago I have relocated /usr/lib64 to another filesystem.
> 
> All the relative symlinks to /lib64 was failed .
> 
> I've recreated all the symlinks and now pango has been build correctly.
> 
> Can you explain how do you diagnose the problem from that error!?!
> 
> I can't understand.

From this:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libm.a

If the compiler can't find the shared library, libm.so, when linking with -lm, it will fallback to the static archive, libm.a

So the first thing that occured to me was:

Why would pango be linking to the static archive?
No reason. Where did his shared library go?

;-)

Closing then
Comment 6 Alessandro Surace 2012-03-21 15:32:29 UTC
Thanks for your explanation