Problem with crosstool on MacOS X

[Dr. H. Nikolaus Schaller]

Am 19.06.2006 um 22:20 schrieb Kai Ruottu:
>
> >  I tried with crosstools-0.38 and 0.42 - no difference.
>
> I suspect this "black box" never trying to teach people to do what  
> I just wrote :-(

Well, that is the idea why everybody wants to use a black box...
And, my target is to make an even more black box, i.e. a wrapper  
around crosstools that provides all the patches needed to run  
crosstools properly on MacOS X. Or at least contribute to the "MacOS  
X how-to".

> > /Developer/Xtoolchain/gcc-2.95.3-glibc-2.2.2/arm-unknown-linux- 
> gnu/arm-unknown-linux-gnu/lib/libc_nonshared.a: could not read  
> symbols:
> > Archive has no index; run ranlib to add one
>
> The library seems to be the ARM one but produced with a wrong 'ar',  
> the native 'ar' or something else but with the ARM one.
>
> system is ready.  Doing this way could be "bad engineering" or the  
> "German method - Switch the power on and then see where
> the smoke rises!" :-)

Well, I am a German :-)

> Probably you will need to do just what was told: "Archive has no  
> index; run ranlib to add one"...  Maybe finding out why this thing
> happened could be motivated but the cure is just this, to use your  
> 'arm-unknown-linux-gnu-ar' to the 'libc_nonshared.a'...  And
> also check that the 'libc.so' script is sane, not having the  
> typical '/lib/libc.so.6 /usr/lib/libc_nonshared.a' for a native  
> install....

It turned out that ranlib is not able to create an index. Even worse,  
the native (MacOS X) ar and the newly created ar (there are in fact 2  
of them: ./build/arm-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.2/build- 
binutils/binutils/ar and  ./build/arm-unknown-linux-gnu/gcc-2.95.3- 
glibc-2.2.2/gcc-core-prefix/arm-unknown-linux-gnu/bin/ar ) both show  
a strange and probably currupt archive:

/Volumes/Xtoolchain/Xtoolchain/crosstool-0.42 hns$ ./build/arm- 
unknown-linux-gnu/gcc-2.95.3-glibc-2.2.2/build-binutils/binutils/ar - 
tv /Developer/Xtoolchain/gcc-2.95.3-glibc-2.2.2/arm-unknown-linux-gnu/ 
arm-unknown-linux-gnu/lib/libc_nonshared.a
rw-r--r-- 502/20      8 Jun 19 22:19 2006 __.SYMDEF SORTED
--------- 0/0    128 Jun 17 15:17 2006 /
rw-r--r-- 502/20    776 Jun 17 15:07 2006 stat.oS/
rw-r--r-- 502/20    784 Jun 17 15:07 2006 fstat.oS/
rw-r--r-- 502/20    784 Jun 17 15:07 2006 lstat.oS/
rw-r--r-- 502/20    800 Jun 17 15:07 2006 mknod.oS/
rw-r--r-- 502/20    760 Jun 17 15:07 2006 stat64.oS/
rw-r--r-- 502/20    760 Jun 17 15:07 2006 fstat64.oS/
rw-r--r-- 502/20    760 Jun 17 15:07 2006 lstat64.oS/

They complain about the / entry and tell that it is a directory.  
Therefore, I can't extract e.g. stat.oS manually. By looking at a  
hexdump of the archive it appears that it contains ARM-ELF binaries.

So, I think I have to find out how and where this corrupt archive is  
created. Might be a common $PATH issue...
Or, it runs the native ranlib which would assume Mach-O object files  
in the archive and corrupts it. This would also be an $PATH issue.

This might be the first part of the answer to this "libiberty no  
targets" FAQ.

More hints still welcome! Maybe, someone who has already solved such  
a problem?

Many thanks so far,
Nikolaus Schaller


--
For unsubscribe information see http://sourceware.org/lists.html#faq