gcc-config and prelink woes

[inciner@tor]

Well, I finally managed to find out that something put in a symlink from /usr/lib/lib to /usr/lib/lib into my filesystem, making prelink unable to work.
Now that has been resolved, I still have another problem, though. It especially regards kde related binaries, but could possibly affect any app or lib written in c++

Here's what I have to report:
prelink -avmf cannot link several libraries, for example it prints:

Code: Select all

prelink: Could not prelink /usr/lib/libfam.so.0 because it doesn't use /lib/libgcc_s.so.1, but one of its dependencies has been prelinked against it

Now I did some ldd
ldd /usr/lib/libfam.so.0 printed out

Code: Select all

libstdc++.so.6 => //usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.so.6 (0xb7f26000)
libgcc_s.so.1 => //usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libgcc_s.so.1

Did you notice the double slash in front of the pathname, that's a wee bit odd, but not the core of the problem.
ldd /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/libstdc++.so.6 printed out

Code: Select all

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41c0b000)

And now comes the hammer: A diff turned out that both libgcc_so.1 files are IDENTICAL. However, if you look at the prelink output, prelink links them both to the SAME address space.

Code: Select all

Laying out 243 libraries in virtual address space 41000000-50000000
Assigned virtual address space slots for libraries:
...
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.3/libgcc_s.so.1       41c0b000-41c13504
...
/lib/libgcc_s.so.1                                           41c0b000-41c13504
...

Just for the fun of it, I deleted /lib/libgcc_s.so* and re-run gcc-config to go to the same profile. gcc-config[i/] copied the right file into /lib. Then I re-ran prelink, but still both libs were put into the same address space.

It is obvious that prelink fails for libfam.so.0, it links against libgcc_s.so.1 (the one in /usr/lib/gcc) AND libstdc++.so.6, but libstdc++.so.6 links against the one in /lib. Since both have the same address space but are treated as different files, prelink cannot possibly pre-link libfam.so.1 as this would cause an address space conflict. A re-install of gcc did not help, as that created the same file setup.

Now my questions is: /lib/libgcc_s.so.1 obviously is a copy of the file in /usr/lib/gcc, made by gcc-config. Should that not be a symlink instead of a copy then? Why does gcc-config not create a symlink instead of making a copy then? I cannot really blame prelink for putting the libs into the same address space. Both libs have the same name and no single binary is ever going to link against BOTH of them. But could then prelink not realise both files are the same and symlink them?

This weird behavious leads to prelink failing for quite a few binaries, therefore effectively failing to prelink kde and maybe some other c++ apps, as well.

I am sort of hesitant to convert /lib/libgcc_s.so.1 into a symlink to the file in /usr/lib/gcc. I suspect that would solve my problem but could break gcc profiles. Doing gcc-config would probably re-create the problem again.

Any serious advice is appreciated.

Cheers,
Dominik

[simondo42]

Hi inciner@tor,

This is really useful stuff -- I have the same problem too (although no solution sorry!). Have you filed a bug report? That might bring it to the attention of the gcc-config/prelink developers.

Cheers,
simon

Edit I bit the bullet and tried symlinking /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/libgcc_s.so to /lib/libgcc_s.so.1 instead of the one in /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/ and then prelinking. Prelink ran through fine with no libgcc_s.so related errors and everything seems to be working on reboot. Haven't tried running gcc-config again to see if it restores the symlinks, but I imagine it does.

[inciner@tor]

Glad to hear somebody else has this problem, too. I won't bother filing a bug report, though. I stopped using Gentoo as of last Friday and I am now a happy user of Arch Linux.

Imho the cleanest solution seems to be changing gcc-config to produce symlinks instead of a local copy. On the other hand, I don't think ebuilds should really link to the copy in /lib anyway. Especially for c++ programs this is bound to get you into serious problems once you change the compiler. With distinct copies of each lib at least the currently installed programs won't stop working until you ebuild new c++ apps. Meanwhile you can let your machine do a revdep-rebuild over night, but that's just my two cents.

I am not sure what re-running gcc-updating might do. If it does not delete the currently existing copy of the lib then things may get really nasty once you had a major gcc update.

Btw, funny: Dunedin <=> Edinburgh *ggg*

Cheers,
Dominik

[simondo42]

Yep, Dunedin -- the Edinburgh of the south Even originally had the same street layout, so I'm told. Still a bit confused about why the Scots would travel half way around the world to set up camp in one of the coldest parts of New Zealand, but since I'm of Scottish ancestary I'm glad they did.

I think it's okay to link into /lib/libgcc_s.so so long as you're upgrading gcc (and setting the link from /usr/lib/gcc... manually), since the files are the same. Not sure what would happen if you changed already installed slotted versions though. It's a kludge though, and bound to bite someone (probably me) on the arse at some point.

I've heard about Arch Linux in passing. What made you decide on that distro (just curious cos I don't know much about it).

Cheers,
simon

[Pubare]

See http://forums.gentoo.org/posting.php?mo ... &p=2125440 for a possible solution.

[simondo42]

Saw that thanks Pubare.

You might want to edit your posting -- the link you gave might not lead where you think it does....

simon

[spiralvoice]

Well, I finally managed to find out that something put in a symlink from /usr/lib/lib to /usr/lib/lib into my filesystem, making prelink unable to work.

I had that link as well with the same results. The creation date matches no emerge activity so I don´t know why it was there...