On Sun, Aug 31, 2008 at 5:55 PM, Stefan Reinauer stepan@coresystems.de wrote:
Sure. A mail with additional information was sent to you by the Wiki.
Thanks
What I'll add is that you need to use a crosscompiler to build successfully the new trunk/filo branch.
Please don't add this, it's not true.
OK I'm trying to understand why it does not work as expected here.
Then something is wrong with your native compiler. None of the x64 systems I've been compiling on requires a compiler. How did you run the make process?
make clean && make
can you try executing
gcc -m32 -print-libgcc-file-name ?
$ gcc -m32 -print-libgcc-file-name /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/32/libgcc.a
And now I'm very confused, because I wanted to add that nm on that library showed missing __udivdi3, but it isn't, I certainly did that when first met the problem and now it does tell me it's there... :-/
OK I did the -print-libgcc-file-name without -m32 at that time, that explains the confusion. the -m32 libgcc.a has the required functions.
And I found why it was failing for me: all the $(CC) calls made in Makefile are not "-m32"-ized, especially the "-print-libgcc-file-name" one...
what gcc version are you using? Looks like your compiler is seriously broken then.
It seems to work fine with the attached (better) patch
Vincent Legoll wrote:
And I found why it was failing for me: all the $(CC) calls made in Makefile are not "-m32"-ized, especially the "-print-libgcc-file-name" one...
So why not just
CC=$(CC) -m32
?
//Peter
On Sun, Aug 31, 2008 at 6:36 PM, Peter Stuge peter@stuge.se wrote:
Vincent Legoll wrote:
And I found why it was failing for me: all the $(CC) calls made in Makefile are not "-m32"-ized, especially the "-print-libgcc-file-name" one...
So why not just
CC=$(CC) -m32
Yes, that's a smaller (better) equivalent patch
On Sun, Aug 31, 2008 at 6:40 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
So why not just
CC=$(CC) -m32
Yes, that's a smaller (better) equivalent patch
Here is what I came with, implementing Peter's idea