1 |
On Thu, 2007-04-26 at 07:51 -0400, Mark Haney wrote: |
2 |
> >> |
3 |
> > |
4 |
> > I did that before I emerged world, I followed the wiki to the letter for |
5 |
> > this upgrade. However, I did shut my system down after emerging system |
6 |
> > and before emerging world (did make sure system rebuilt completely), |
7 |
> > could that have something to do with it? |
8 |
> > |
9 |
> > |
10 |
> |
11 |
> I completely walked back through the upgrade process last night. After |
12 |
> an emerge of system, I still do not have that file in |
13 |
> /usr/lib64/gcc/x86_64-pc-linux-gnu/4.1.1. Is that file not supposed to |
14 |
> have been created with fix_lib_tools.sh? |
15 |
> |
16 |
|
17 |
I don't think that file is supposed to exist at all; at least, I have |
18 |
libstdc++.a and libstdc++.so, but not libstdc++.la. No, |
19 |
fix_libtool_files.sh won't create any .la files; what it does is scan |
20 |
your system looking for .la files with hard references to the old (now |
21 |
gone) compiler, and fix them to point to the new compiler. I'd guess |
22 |
that this is your problem: some .la file on your system had a pointer to |
23 |
libstdc++.la on the old compiler, which was fixed to point to the new |
24 |
compiler, but gcc is no longer installing that file. Try this: |
25 |
|
26 |
Run: |
27 |
find / -name "*.la" -exec grep -H libstdc++.la {} \; |
28 |
|
29 |
For each hit, use equery b (or equivalent) to find out which package |
30 |
owns that file, and re-emerge that package. I'd guess that should solve |
31 |
your problem, although you may find some of those packages depend on |
32 |
each other, so the order of re-emerging may be important. |
33 |
|
34 |
Daniel |
35 |
|
36 |
-- |
37 |
gentoo-amd64@g.o mailing list |