Douglas Campos wrote:
> I've found that using gcc-3.4.4-r1 made a lot of python modules going
> with "unresolved symbols", even when they compiled shamelessly
>
> I switched to gcc-3.3.6 and then everything went right!
>
> Just some food for thought.
>
> Cheers
>
> Douglas
This is very interesting. I am trying to test out whether this will fix
my problem ("unresolved symbol" in libsvn Python module) by emerging
gcc-3.3.6 but it's not happy.
I am using softfloat (my host type is armeb-softfloat-linux-uclibc), and
have successfully emerged gcc-3.4.4* in the past, but in gcc-3.3.6 I
(eventually) get a whole bunch of errors like:
/usr/armeb-softfloat-linux-uclibc/bin/ld: ERROR: ./crtbeginS.o uses FPA
instructions, whereas libgcc_s.so.1 does not
/usr/armeb-softfloat-linux-uclibc/bin/ld: ERROR: ./crtbeginS.o uses
hardware FP, whereas libgcc_s.so.1 uses software FP
/usr/armeb-softfloat-linux-uclibc/bin/ld: failed to merge target
specific data of file ./crtbeginS.o
...
Maybe this is a problem with the gcc-3.3.6 ebuild? Is there something I
can set in my CFLAGS for the gcc emerge that will tell it to use softfloat?
(All these problems have made me start to regret fooling around with
bizarre embedded arches ...! :-D)
--
Dan C <[EMAIL PROTECTED]>
--
[email protected] mailing list
