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

[Farox]

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.

 

[Farox]

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

 

[notaz]

Where have you found that ./configure thing? Drivers usually don't need such things.

 

[Farox]

Linux drivers for Epson printer (i have xp-312)

http://download.ebz.epson.net/dsc/search/01/search/searchModule

http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=IT&CN2=&DSCMI=42302&DSCCHK=8b574d657ed13278da38b541f7cecc5b6330c12c

 

[levi]

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.

 

[ptitSeb]

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...

 

[levi]

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.

 

[ptitSeb]

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 ?

 

[levi]

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.

 

[ptitSeb]

Do you have an export called AS maybe?

 

[levi]

Nope, echo $AS returns nothing (and neither does echo $as or echo $As).

 

[ptitSeb]

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.

 

[ptitSeb]

The crosscompilemaker.sh v1.2 is uploaded. I fixed a mistake introduced in 1.1. It should works fine now (and that should fix your issue @Levi).

 

[levi]

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.