Re: [gentoo-user] Upgrading tetex, not finding crti.o [solved]

2006-12-02 Thread Bertram Scharpf
Hi Richard,

Am Donnerstag, 30. Nov 2006, 19:54:33 -0700 schrieb Richard Fish:
 On 11/30/06, Bertram Scharpf [EMAIL PROTECTED] wrote:
 Sorry, the output of '... 21 myfile' seems not to happen
 in the correct order.
 
 Just for future reference, you want myfile 21.

Oh, I learned this for several times. I hope I can keep it
this time.

   http://www.bertram-scharpf.de/tmp/emerge-info
   http://www.bertram-scharpf.de/tmp/emerge-vuD-tetex
 
 Ok, a few things:
 
 1) in your original message, you stated that you had a directory
 
 /usr/lib/gcc/i386-pc-linux-gnu/3.4.6
 
 In fact, based on your emerge --info, you should have:
 
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6
 
 Was this a typo in your original message, or do you have both i386-
 and i686- compilers installed?  (gcc-config -l)

Oops. Indeed I have installed `gcc' twice. SLOT=1 has
version 3.4.6 and SLOT=2 has 4.1.1 . I managed to solve this
with the following steps:

  - remove the 3.4.6 version by emerge -C ...
(almost nothing works now)
  - create symlinks /usr/i386-pc-linux-gnu/gcc-bin - ..i686...
/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 - ... /4.1.1
  - re-emerge gcc, glibc and several other packages

This was probably too much effort, but I'm happy that it
works at all.

The package tetex is compiling without complaint now.

Thank you very much.

Bertram



-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o [solved]

2006-12-02 Thread Richard Fish

On 12/2/06, Bertram Scharpf [EMAIL PROTECTED] wrote:

  - remove the 3.4.6 version by emerge -C ...
(almost nothing works now)
  - create symlinks /usr/i386-pc-linux-gnu/gcc-bin - ..i686...
/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 - ... /4.1.1
  - re-emerge gcc, glibc and several other packages

This was probably too much effort, but I'm happy that it
works at all.


Ok, it sounds like you just upgraded gcc versions.  So an emerge -e
world is called for if you want to be safe.

-Richard
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-30 Thread Bertram Scharpf
Hi Richard,

Am Mittwoch, 29. Nov 2006, 13:12:17 -0700 schrieb Richard Fish:
 On 11/29/06, Bertram Scharpf [EMAIL PROTECTED] wrote:
 I am trying to upgrade teTex using `emerge -pvuD tetex'. The
 compiling process aborts with an error message saying that
 this file could not be found:
 
   /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/../../../crti.o
 
 Can you post your emerge --info, and the everything between the make
 command that caused this error to the end of the emerge output.  The
 last 20-30 lines of build output should suffice if you can identify
 the make command that caused the problem.

Sorry, the output of '... 21 myfile' seems not to happen
in the correct order.

  http://www.bertram-scharpf.de/tmp/emerge-info
  http://www.bertram-scharpf.de/tmp/emerge-vuD-tetex

Bertram


-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-30 Thread Richard Fish

On 11/30/06, Bertram Scharpf [EMAIL PROTECTED] wrote:

Sorry, the output of '... 21 myfile' seems not to happen
in the correct order.


Just for future reference, you want myfile 21.  The order is
significant, as the command that you ran first redirected stderr to
the same location as stdout, _then_redirected stdout to the file,
leaving stderr pointing at whatever stdout was going to.  Reversing
the order first redirects stdout to the file, then redirects stdout to
the same place.


  http://www.bertram-scharpf.de/tmp/emerge-info
  http://www.bertram-scharpf.de/tmp/emerge-vuD-tetex


Ok, a few things:

1) in your original message, you stated that you had a directory

/usr/lib/gcc/i386-pc-linux-gnu/3.4.6

In fact, based on your emerge --info, you should have:

/usr/lib/gcc/i686-pc-linux-gnu/3.4.6

Was this a typo in your original message, or do you have both i386-
and i686- compilers installed?  (gcc-config -l)

2) Assuming you don't have multiple compilers installed, I don't
understand why you have an i386-pc-linux-g++ command.  Where is this
located (which i386-pc-linux-g++), and what owns it (equery belongs
i386-pc-linux-g++)?

3) It looks like you changed from a i386 CHOST to i686, in addition to
changing compiler versions.  In this case, you need to do:

fix_libtool_files.sh 3.4.5 --oldarch i386-pc-linux-gnu

Just a quick explanation of libtool and why that command is needed:
normally when a program is compiled and linked against dynamic
libraries, the link command must include all dependent libraries as
well.  So if I link prog against  liba.so, and liba.so requires
libb.so, I must include both liba and libb on the link command for
prog or I will end up with unresolved symbol errors.

But this is really a nightmare, because liba may only /sometimes/
depend on libb, depending upon what options liba was compiled with.
Determining which systems needs to link against libb and which ones do
not was very problematic.  This is the problem that libtool is
intended to solve, and it does it fairly well.

If prog and liba both use libtool, then when liba is compiled and
installed, there is a libtool archive (.la) file that is generated and
installed at the same time.  This archive contains the link options
required to successfully link against liba, including any dependent
libraries.  So when the build process for prog is linked, it uses
libtool, and tells libtool to link prog against liba.  Libtool looks
in the .la file for liba, and sees that linking against libb is also
required, and adds it automatically.

The problem that gcc-upgrades introduce to this system though is that
the libtool files contain references to object (.o) files located in
the gcc installation.  When you upgrade gcc, the directory structure
changes, and the libtool files now reference files that do not exist.

So, fix_libtool_files.sh was created for gentoo systems to correct all
libtool archives.

HTH,
-Richard
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-30 Thread Randy Barlow
Richard Fish wrote:
 1) in your original message, you stated that you had a directory
 
 /usr/lib/gcc/i386-pc-linux-gnu/3.4.6
 
 In fact, based on your emerge --info, you should have:
 
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6
 
 Was this a typo in your original message, or do you have both i386-
 and i686- compilers installed?  (gcc-config -l)
 
 2) Assuming you don't have multiple compilers installed, I don't
 understand why you have an i386-pc-linux-g++ command.  Where is this
 located (which i386-pc-linux-g++), and what owns it (equery belongs
 i386-pc-linux-g++)?

Something that's been bugging me about my system - I accidentally used
an i386 stage 3 when I installed, and didn't notice until long after the
machine was configures.  Can I just change the CHOST setting to i686 and
use fix_libtool_files.sh along with an emerge world or something like
that?  Would this destroy my system?  Is there any benefit at all to
using an i686 CHOST as opposed to i386?  Thanks!

-- 
Randy Barlow
http://www.electronsweatshop.com
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-30 Thread Richard Fish

On 11/30/06, Randy Barlow [EMAIL PROTECTED] wrote:

Something that's been bugging me about my system - I accidentally used
an i386 stage 3 when I installed, and didn't notice until long after the
machine was configures.  Can I just change the CHOST setting to i686 and
use fix_libtool_files.sh along with an emerge world or something like
that?


You end up recompiling *everything*.  But there is a guide to help you:

http://www.gentoo.org/doc/en/change-chost.xml


Would this destroy my system?


It should be possible to do safely, but I would make a backup just in
case, and since you are about to emerge -e world anyway, make sure you
have some down time available.


Is there any benefit at all to using an i686 CHOST as opposed to i386?


Yes.  For one thing it allows you to use nptl which is more efficient
for threading than pthreads.  In fact, glibc-2.5 is nptl _only_, so
upgrading to glibc-2.5 will require CHOST to be i486 or better.

-Richard
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-29 Thread Bertram Scharpf
Hi Randy,

Am Mittwoch, 29. Nov 2006, 13:55:14 -0500 schrieb Randy Barlow:
 fix_libtool_files.sh 3.4.5
 
 That should do the trick :)

Sorry, it seems it doesn't. What kind of tool is that?

Bertram


 Bertram Scharpf wrote:
 I am trying to upgrade teTex using `emerge -pvuD tetex'. The
 compiling process aborts with an error message saying that
 this file could not be found:
 
   /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/../../../crti.o
 
  [...] present is
 
   /usr/lib/gcc/i386-pc-linux-gnu/3.4.6/../../../crti.o
  ^
 
 How can I tell the ebuild that my compiler is version 3.4.6?

-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-29 Thread Richard Fish

On 11/29/06, Bertram Scharpf [EMAIL PROTECTED] wrote:

Hi,


I am trying to upgrade teTex using `emerge -pvuD tetex'. The
compiling process aborts with an error message saying that
this file could not be found:

  /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/../../../crti.o


Can you post your emerge --info, and the everything between the make
command that caused this error to the end of the emerge output.  The
last 20-30 lines of build output should suffice if you can identify
the make command that caused the problem.

Thanks,
-Richard
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Upgrading tetex, not finding crti.o

2006-11-29 Thread Randy Barlow

Bertram Scharpf wrote:

Sorry, it seems it doesn't. What kind of tool is that?
  
Hmm, I actually don't know all that much about it, but it mentions it 
here: http://www.gentoo.org/doc/en/gcc-upgrading.xml and I've been 
advised to use it for a similar problem before.  Have a look at 
http://bugs.gentoo.org/show_bug.cgi?id=73435  Specifically, try 
re-emerging libtool and see if that fixes your problem.  If not, try 
fix_libtool_files.sh after re-emerging libtool.  If not, submit a bug?


Randy
--
gentoo-user@gentoo.org mailing list