WiFi usb-stick problems(Need to manualy Compile the Driver)


Ok i build the toolchain with ptitSeb script (first version) and worked fine after resizing (from 8GB to 24GB)  the virtual image.

It builded an armv7-linux-gnueabi toolchain...that builded fine the second part with notaz suggested command.

Now to experiment building some driver...just for fun ;)

What command to use to cross compile with configure ?

with this....

./configure --host=armv7l-unknown-linux-gnueabi

doesn't find the correct gcc...and compile for x86.... :(

Any help ?

Thanks guys.
 
Last edited by a moderator:
Sorry for double post...but this cross compile thing wtih configure drives me crazy...

what is the correct sequence of commands ? i'll end always building for x86....... :wacko:

Thanks
 
I'm building the cross compiler toolchain, and I get the following:

patching file glibc-2.9/configure
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file glibc-2.9/configure.rej
patching file glibc-2.9/manual/Makefile
Configuring glibc
Error on step 5, aborting...

I entered the two 'no' answers, as I assume if the patch matches what's already there, you shouldn't reapply it or reverse it, but I guess that was enough to flag the stage as faulty.

It's possible I've messed up the script, as I had to adapt it both to use 'curl -LO' instead of 'wget', and knock out all the zenity stuff (and hardcode the answers) because I'm running it on a build server that doesn't have graphics.  But I don't think I touched the patches, and I can't imagine how I would have accidentally made the patched text match.
 
I'm building the cross compiler toolchain, and I get the following:

patching file glibc-2.9/configure
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file glibc-2.9/configure.rej
patching file glibc-2.9/manual/Makefile
Configuring glibc
Error on step 5, aborting...

I entered the two 'no' answers, as I assume if the patch matches what's already there, you shouldn't reapply it or reverse it, but I guess that was enough to flag the stage as faulty.

It's possible I've messed up the script, as I had to adapt it both to use 'curl -LO' instead of 'wget', and knock out all the zenity stuff (and hardcode the answers) because I'm running it on a build server that doesn't have graphics.  But I don't think I touched the patches, and I can't imagine how I would have accidentally made the patched text match.

You can remove the glibc-2.9 folder completely, it will extract and patch again, just to be sure (strange that only 1 patch has been applied and not the other).

If it still cannot pass step 5, I'll need  the logs...
 
It does appear to try to patch configure twice.  First, it patches it once, then it patches elf/Makefile, then it tries to patch configure again.

Looking into all.log and error.log, it does seem to get to running configure but then that fails, probably for a different reason.  all.log ends with 'checking for suffix of object files...' then error.log contains 'configure: error: cannot compute suffix of object files: cannot compile'

config.log in /pandora_cross/build_glibc/ has some interesting titbits which look related:

gcc version 4.9.3 (GCC)
configure:3284: $? = 0
configure:3291: armv7l-unknown-linux-gnueabi-gcc -V >&5
armv7l-unknown-linux-gnueabi-gcc: error: unrecognized command line option '-V'
armv7l-unknown-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
configure:3294: $? = 1
configure:3298: checking for suffix of object files
configure:3324: armv7l-unknown-linux-gnueabi-gcc -c   conftest.c >&5
as: unrecognized option '-mcpu=cortex-a8'
configure:3327: $? = 1

If I run the built arm gcc, it seems to repond well to '--version' but badly to '-V'.  I've no idea why it doesn't recognise the -mcpu option.

In case it's relevant, my version of autoconf responds that it's version 2.69.  Diff is version 3.3.
 
The patch thing is odd, I must have messed up the v1.1 I guess :(

But for your issue, it seems is not calling the right assembler, it should call armv7l-unknown-linux-gnueabi-as and I think it just called regular as. Do you see the as program in your cross compile "bin" folder ?
 
Yes, it's there and calling it with --version reponds as 'GNU assembler (GNU Binutils) 2.25.1', and 'This assembler was configured for a target of `armv7l-unknown-linux-gnueabi'.'

Is there some test code I can build?  I checked for this mythical conftest.c, but I guess that's built on the fly by configure, as I can't find it in pandora_cross.
 
I don't know. I have to check more on my side. Can you provide your modifier script so I can test on my side.
 
Thanks very much!  I had to back it off a few stages, but re-running it from stage 2 it's sailed past stage 5 fine this time, and is now into compiling the GCC libs.
 
Back
Top