I can built scratchbox: data host computer: linux debian etch (x86) (kernel 2.6.18) I have done your readme in order but When I run ----- snip ------ $HOME/scratchbox/bin/sb2-init /usr/local/arm/arm-2007q1/bin/arm-none-linux-gnueabi-gcc Finished writing sb2.config --13:42:20-- http://ftp.funet.fi/pub/mirrors/ftp.gnu.org/pub/gnu/libtool/libtool-1.5.22.tar.gz => `libtool-1.5.22.tar.gz' Resolviendo ftp.funet.fi... 193.166.3.2, 2001:708:10:9::20:1 Connecting to ftp.funet.fi|193.166.3.2|:80... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 2,921,483 (2.8M) [application/x-gzip] 100%[====================================>] 2,921,483 64.29K/s ETA 00:00 13:43:07 (63.84 KB/s) - `libtool-1.5.22.tar.gz' saved [2921483/2921483] checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Running /home/programador/scratchbox/bin/sb2-build-libtool failed You can run this manually later, otherwise your sb2 environment is correctly setup and ready to use ----- snip ------ sb2.config # Scratchbox2 configuration file generated by sb2-init. SBOX_CPU=arm SBOX_OS=none-linux-gnueabi SBOX_CPUTRANSPARENCY_METHOD=/usr/local/bin/qemu-arm SBOX_DEFAULT_GCC_PREFIX=arm-none-linux-gnueabi- SBOX_CROSS_GCC_NAME=cross-gcc SBOX_CROSS_GCC_PREFIX_LIST=none-linux-gnueabi-:arm-linux-:arm-none-linux-gnueab SBOX_CROSS_GCC_SUBST_PREFIX=arm-none-linux-gnueabi- SBOX_CROSS_GCC_SPECS_FILE= SBOX_CROSS_GCC_DIR=/usr/local/arm/arm-2007q1/bin SBOX_CROSS_GCC_LD_ARGS= SBOX_HOST_GCC_NAME=host-gcc SBOX_HOST_GCC_PREFIX_LIST=host- SBOX_HOST_GCC_SUBST_PREFIX= SBOX_HOST_GCC_SPECS_FILE= SBOX_HOST_GCC_DIR=/usr/bin SBOX_HOST_GCC_LD_ARGS= ---------- arch should it be armel, but I don't think problem is there
Do you use the user-space from the codesourcery toolchain? If yes, the problem is most likely in qemu's missing/incomplete EABI support.
(In reply to comment #1) > Do you use the user-space from the codesourcery toolchain? If yes, the problem > is most likely in qemu's missing/incomplete EABI support. I have downloaded qemu cvs as sb2 how-to comment and make and install it Do you think is a problem with qemu and EABI?, It sounds stranger because maemo is EABI and it's working with scratchbox1 Could you please try sb2 for a arm EABI by yourself in order to confirm it, I downloaded codesourcery toolchain for arm and for linux version arm-2007q1
Yes, I'm quite sure the problem is in qemu. I'm not sure what's different with the glibc shipped with codesourcery vs. maemo's, but it seems to be causing problems for qemu. Maemo is indeed EABI as well.
(In reply to comment #3) > Yes, I'm quite sure the problem is in qemu. I'm not sure what's different with > the glibc shipped with codesourcery vs. maemo's, but it seems to be causing > problems for qemu. Maemo is indeed EABI as well. I have found this message about Qemu and EABI, please read it http://www.cygwin.com/ml/crossgcc/2006-05/msg00019.html
I had that printout before I applied the patch in bug 17306. Why would it be a bug in QEMU related to EABI? AFAICT the libtool build script is trying to cross-compile libtool without using any emulation whatsoever, so QEMU doesn't even enter the picture. I would rather suspect that libtool cross-compiles better with the --build option set to some specific host triplets, and other, more complex prefixes like rm-none-linux-gnueabi- will make it fail.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.