could not read symbols: Archive has no index

[durgeshsanagaram]

Hi,

I am trying to port c & c++ open source code onto embedded target(MIPS).It compiles fine on x86/RH4. When I try embedded platform specific tool chain as follows, I get following error.

1)mipsel-linux-uclibc-cpp -O2 -g -Wall -Werror xyz.c xyz.o
mipsel-linux-uclibc-cpp -O2 -g -Wall -Werror pqr.c pqr.o
SUCCESS.Objects are ready
2)mipsel-linux-uclibc-ar -rcsv ../libs/ttt.a xyz.o pqr.o
SUCCESS. Static Library is ready
3)mipsel-linux-uclibc-ranlib libs/ttt.a libs/ttt.a
Fine. No warnings
4)mipsel-linux-uclibc-gcc -g -o ../bin/ttt_binary ttt.o ../libs/ttt.a ../libs/abc.a
ERROR:
could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status

I tried different combinations. It did not help. My idea is to port an open source code that works fine on X86/Linux to an embedded target based on MIPS.

Thankyou

[Rubberman]

Run the embedded (mips) toolchain ranlib on the library and see if it then links ok. I haven't worked with MIPS tool chains - which distribtuion+version of Linux + kernel are you building for? I have some experience with embedded ARM processors building the kernel on my CentOS 5.4 workstation. Applications I normally build on the embedded board once I have the kernel built, but that isn't necessary normally - just quicker since I don't have to copy the targets (executable + libraries) to the embedded device to test them out.

[drl]

Hi.

I don't know anything about MIPS cross-compiling, but I think the problem is with:

mipsel-linux-uclibc-cpp -O2 -g -Wall -Werror xyz.c xyz.o

The cpp command is for preprocessing text to deal with constructs such as defines, includes. Your note suggests that you think it produces relocatables:

SUCCESS.Objects are ready

When I tried:

cpp -O2 -g -Wall -Werror a.c a.o

for a trivial code:

void a()
{
  return;
}

the content of a.o was not a relocatable code, but rather something like:

# 1 "a.c"
# ...
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.c"
void a()
{
  return;
}

and

file a.o

returns

a.o: ASCII text

The ar and ranlib run happily with such text files, but ld does not, producing the error message you saw.

If you were to replace cpp with gcc, I think you would get farther. You would also need to add "-c" to the gcc calls, for example:

gcc -O2 -g -Wall -Werror -c a.c

When I made changes like that to a similar command sequence, the link resulted in a file ttt_binary, which, when examined by file:

file bin/ttt_binary

was:

bin/ttt_binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped

Best wishes ... cheers, drl

[durgeshsanagaram]

Thankyou DRL and Rubberman.

After moving from mips-linux-uclibc-cpp to mips-linux-uclibc_gcc as suggested by DRL, the problem disappeared. Now, I see the symbols in objdump. Archive seems to have index and the final binary compiles without the error "could not read symbols:Archive has no index". I am yet to execute.

But the problem I am having is that the open source that I am using as a reference is a combination of CPP and C files. 80% of it is C code and 20% of it is CPP. The CPP code accepts command lines, derives some other information and passes it to C programs.

I am left with two options
1) Convert portion of C++ code to c code. Somewhat involved.
2) Find an option in mips-linux-uclibc-cpp (instead of gcc) that generates proper symbols. Why
mips-linux-uclibc-cpp did not generate proper symbols and file format whereas mips-linux-uclibc-gcc did? I use BRCM tool chain.

mips-linux-uclibc-gcc that works:
mipsel-linux-uclibc-gcc -c -O2 -g -Wall -Werror -I../include -I. xyz.c -o ../objs/xyz.o

mips-linux-uclibc-cpp that does not work (meaning does not generate symbols)
mipsel-linux-uclibc-cpp -O2 -g -Wall -Werror -I../include -I. pqr.cpp -o ../objs/pqr.o

Any thoughts would be helpful.

Thankyou.

[Rubberman]

Is there a mips-linux-uclibc-g++ compiler? That is the C++ compiler which should deal with .cpp files just fine. It avoids having to convert C++ to C program code, which can be pretty much impossible in many cases, especially for more up-to-date code bases.