| 1 |
On 11/30/06, Bertram Scharpf <lists@×××××××××××××××.de> wrote: |
| 2 |
> Sorry, the output of '... 2>&1 >myfile' seems not to happen |
| 3 |
> in the correct order. |
| 4 |
|
| 5 |
Just for future reference, you want ">myfile 2>&1". The order is |
| 6 |
significant, as the command that you ran first redirected stderr to |
| 7 |
the same location as stdout, _then_redirected stdout to the file, |
| 8 |
leaving stderr pointing at whatever stdout was going to. Reversing |
| 9 |
the order first redirects stdout to the file, then redirects stdout to |
| 10 |
the same place. |
| 11 |
|
| 12 |
> http://www.bertram-scharpf.de/tmp/emerge-info |
| 13 |
> http://www.bertram-scharpf.de/tmp/emerge-vuD-tetex |
| 14 |
|
| 15 |
Ok, a few things: |
| 16 |
|
| 17 |
1) in your original message, you stated that you had a directory |
| 18 |
|
| 19 |
/usr/lib/gcc/i386-pc-linux-gnu/3.4.6 |
| 20 |
|
| 21 |
In fact, based on your emerge --info, you should have: |
| 22 |
|
| 23 |
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6 |
| 24 |
|
| 25 |
Was this a typo in your original message, or do you have both i386- |
| 26 |
and i686- compilers installed? (gcc-config -l) |
| 27 |
|
| 28 |
2) Assuming you don't have multiple compilers installed, I don't |
| 29 |
understand why you have an i386-pc-linux-g++ command. Where is this |
| 30 |
located (which i386-pc-linux-g++), and what owns it (equery belongs |
| 31 |
i386-pc-linux-g++)? |
| 32 |
|
| 33 |
3) It looks like you changed from a i386 CHOST to i686, in addition to |
| 34 |
changing compiler versions. In this case, you need to do: |
| 35 |
|
| 36 |
fix_libtool_files.sh 3.4.5 --oldarch i386-pc-linux-gnu |
| 37 |
|
| 38 |
Just a quick explanation of libtool and why that command is needed: |
| 39 |
normally when a program is compiled and linked against dynamic |
| 40 |
libraries, the link command must include all dependent libraries as |
| 41 |
well. So if I link "prog" against liba.so, and liba.so requires |
| 42 |
libb.so, I must include both liba and libb on the link command for |
| 43 |
prog or I will end up with unresolved symbol errors. |
| 44 |
|
| 45 |
But this is really a nightmare, because liba may only /sometimes/ |
| 46 |
depend on libb, depending upon what options liba was compiled with. |
| 47 |
Determining which systems needs to link against libb and which ones do |
| 48 |
not was very problematic. This is the problem that "libtool" is |
| 49 |
intended to solve, and it does it fairly well. |
| 50 |
|
| 51 |
If prog and liba both use libtool, then when liba is compiled and |
| 52 |
installed, there is a libtool archive (.la) file that is generated and |
| 53 |
installed at the same time. This archive contains the link options |
| 54 |
required to successfully link against liba, including any dependent |
| 55 |
libraries. So when the build process for prog is linked, it uses |
| 56 |
libtool, and tells libtool to link prog against liba. Libtool looks |
| 57 |
in the .la file for liba, and sees that linking against libb is also |
| 58 |
required, and adds it automatically. |
| 59 |
|
| 60 |
The problem that gcc-upgrades introduce to this system though is that |
| 61 |
the libtool files contain references to object (.o) files located in |
| 62 |
the gcc installation. When you upgrade gcc, the directory structure |
| 63 |
changes, and the libtool files now reference files that do not exist. |
| 64 |
|
| 65 |
So, fix_libtool_files.sh was created for gentoo systems to correct all |
| 66 |
libtool archives. |
| 67 |
|
| 68 |
HTH, |
| 69 |
-Richard |
| 70 |
-- |
| 71 |
gentoo-user@g.o mailing list |
Archives