Re: Quest for missing symbols: __gxx_personality_v0 solved, __fixdfsi not

On Tue Mar 11, 2003 at 10:46:36AM -0800, David Wuertele wrote:
> For those of you not religiously following our hero's story (that's my
> story, by the way): I've got an important module for my embedded
> system that compiles and insmods fine when I use the glibc-based
> algorithmics toolchain, but when I use uclibc that module will not
> insmod and complains that about twenty symbols are not defined.  These
> symbols appear to be a result of using mipsel-uclibc-g++ to compile
> parts of the module.

You are using C++ within the kernel?  Ewww.   I hope you have
taken great care to not do illegal things.  For example, using
libstdc++, exceptions, using any floating point ops, and all
sortof of other things are  forbidden.

> Now that I've tracked down and eliminated __gxx_personality_v0, I'm
> going after __fixdfsi.  I've reduced the module to a tiny test case
> that has the same problem:
> 
> /* test.c:  compile with mipsel-uclibc-g++ -fno-pic -msoft-float -o test.o -c 
> test.cpp
> long ati_floor (double a)
> {
>   return (long) a;
> }

Add a "-v" to your compile and watch what happens during the link.
In particular watch for libgcc....  I think you are trying to
dynamically link vs libgcc, which simply isn't going to work.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--