This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]