This is the mail archive of the
crossgcc@sourceware.org
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
more information.
Re: Problem with crosstool on MacOS X
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