[Scratchbox-users] New release: scratchbox-devkit-doctools 1.0.9
New releases: = * scratchbox-devkit-doctools 1.0.9 Highlights: === * Fixed DocBook issue with missing catalogs DocBook * Fixes issue with building JadeTeX Notes: == * Apophis R4 wiki page [1] contains the information on known issues and other release specific things Report bugs to scratchbox.org bugzilla. Happy hacking, Jussi [1] http://scratchbox.org/wiki/Apophis-r4 ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] Integrating ARM7 gcc 2.95 in Scratchbox 1 or 2
Jan Dohl ha scritto:
Claudio Scordino wrote:
SCRATCHBOX 2
On Scratchbox2, instead, if I type
sb2-init test /usr/local/LxNETES-2.3/arm-elf/bin/arm-elf-gcc
I obtain
[...]
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
If I look at ~/.scratchbox2/libtool_build/config.log I read
gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from
http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from
http://www.snapgear.com/)
configure:2849: $? = 0
configure:2856: gcc -V >&5
arm-elf-gcc: invalid version number format
configure:2859: $? = 1
configure:2882: checking for C compiler default output file name
configure:2909: gccconftest.c >&5
cc1: Invalid option `-Wno-poison-system-directories'
configure:2912: $? = 1
configure:2950: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "libtool"
| #define PACKAGE_TARNAME "libtool"
| #define PACKAGE_VERSION "1.5.26"
| #define PACKAGE_STRING "libtool 1.5.26"
| #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
| #define PACKAGE "libtool"
| #define VERSION "1.5.26"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2957: error: C compiler cannot create executables
See `config.log' for more details.
Hello,
it's kinda a shot in the blue, but I had a very similar problem that SB2
failed to execute arm-binaries through qemu. Assuming that the compiler
and qemu is setup correctly (it creates binaries that you can run with
qemu) you may try to replace the line in the sb2.config which says
export SBOX_CPUTRANSPARENCY_METHOD="qemu-arm"
with something that contains the whole path to the qemu-arm binary, for
me this was
export SBOX_CPUTRANSPARENCY_METHOD="/usr/bin/qemu-arm"
This fixed the problem for me.
I found the problem to be in the "-Wno-poison-system-directories"
option in sb2-init.
I can make sb2-init work if I remove this option.
Maybe gcc 2.95 doesn't support this option ?
Is it _strictly_ necessary ? Can it be safely removed ?
Many thanks,
Claudio
Jan
___
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
--
Ing. Claudio Scordino
Software Engineer, PhD
Tel. +39-050-5492050
http://retis.sssup.it/~scordino/
Evidence Srl
Embedded Real-Time Solutions
http://www.evidence.eu.com
___
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] Integrating ARM7 gcc 2.95 in Scratchbox 1 or 2
2008/9/9 Claudio Scordino <[EMAIL PROTECTED]>: > I found the problem to be in the "-Wno-poison-system-directories" option in > sb2-init. > > I can make sb2-init work if I remove this option. > > Maybe gcc 2.95 doesn't support this option ? > > Is it _strictly_ necessary ? Can it be safely removed ? That is a codesourcery toolchain specific option which makes the warnings about including some (usually) host-system directories in the include path while cross compiling go away. Both scratchboxen emulate compiling in the target system and do have /usr/inlcude etc in the include path. While omitting the option only emits warnings, those warnings are known to cause trouble with configuration scripts and -Werror (making compilation tests fail). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] Integrating ARM7 gcc 2.95 in Scratchbox 1 or 2
Kalle Vahlman ha scritto: 2008/9/9 Claudio Scordino <[EMAIL PROTECTED]>: I found the problem to be in the "-Wno-poison-system-directories" option in sb2-init. I can make sb2-init work if I remove this option. Maybe gcc 2.95 doesn't support this option ? Is it _strictly_ necessary ? Can it be safely removed ? That is a codesourcery toolchain specific option which makes the warnings about including some (usually) host-system directories in the include path while cross compiling go away. I see. However, this doesn't allow to integrate toolchains not from Codesourcery. For instance, I can't integrate my toolchain if I don't remove this option. Instead, if I remove the option and I start using a Codesourcery toolchain, the output is full of warnings (but at least working). In my opinion, it would be more reasonable to provide the possibility of specifying toolchain-specific options during sb-init. For instance: sb2-init -c "-Wno-poison-system-directories" path/to/codesourcery/toolchain sb2-init path/to/not/codesourcery/toolchain Otherwise, we should remove the option and tell people using Codesourcery toolchains to add the option to the SBOX_EXTRA_CROSS_COMPILER_ARGS variable in .scratchbox2//sb2.config What do you think ? Thanks, Claudio ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
[Scratchbox-users] New user asks for guidance
Hi, My goal is to use my working TimeSys toolchain, (based on Code Sourcery ARM9 gcc-4.2 eabi) as a foreign toolchain under Scratchbox. This has tools like armv5l-linux-gcc, full complement of binutils, etc. I have armv5l glibc root file system. All of this is already installed as per TimeSys instructions and ends up at /opt/timesys/ . . . . My host machine is Debian - Lenny (beta2). I also have a target from Atmel - at91sam9263-ek board that has Linux running on it and is network capable. Regarding Scratchbox, I've downloaded and setup Scratchbox Apophis and successfully completed an ARM cross-compile and emulation using Qemu with out-of-the-box tool chains. This was a good start to understanding how powerful this environment really is. These toolchains are not matched up for my particular ARM target and that is where the TimeSys toolchain comes into the picture. My concern is whether I'm on the right path using Scratchbox Apophis, and whether I can make the TimeSys toolchain work w/ Scratchbox plus be able to emulate eabi code using Qemu. Anyone have some opinions regarding this approach and how to make it work, what to watch out for? How hard is this going to be? --Jeff Franks ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] Integrating ARM7 gcc 2.95 in Scratchbox 1 or 2
2008/9/9 Claudio Scordino <[EMAIL PROTECTED]>: > Kalle Vahlman ha scritto: >> >> 2008/9/9 Claudio Scordino <[EMAIL PROTECTED]>: >>> >>> I found the problem to be in the "-Wno-poison-system-directories" option >>> in >>> sb2-init. >>> >>> I can make sb2-init work if I remove this option. >>> >>> Maybe gcc 2.95 doesn't support this option ? >>> >>> Is it _strictly_ necessary ? Can it be safely removed ? >> >> That is a codesourcery toolchain specific option which makes the >> warnings about including some (usually) host-system directories in the >> include path while cross compiling go away. > > I see. However, this doesn't allow to integrate toolchains not from > Codesourcery. Heh, I never said it has any businness being unconditionally in sb2-init :) As you say, it's a compiler-specific option and should definitely be optional. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] Integrated toolchain doesn't look in /usr/lib and /usr/local/lib
Le Tue, 9 Sep 2008 14:45:52 -0700, "L A" <[EMAIL PROTECTED]> a écrit : > For your problem: you might want to check the environment variables > and symbolic links under your scratchbox home directory. Which one should I check specifically ? The same Scratchbox installation works perfectly with an official Scratchbox toolchain. > And I have a question for you: I never got the scratchbox to run mips > binaries (neither with qemu or sbrsh). How did you got it work? I did nothing special: configure a target for mips, select Qemu as the CPU transparency method, and voila. It just worked. Scratchbox by default already configures mips as a supported platform with regard to the binfmt_misc facility: $ ls /proc/sys/fs/binfmt_misc/ jarregistersbox-crissbox-powerpc sbox-win openjdk-6 sbox-armsbox-mipssbox-sh status python2.5 sbox-armeb sbox-mipsel sbox-sparcwine $ cat /proc/sys/fs/binfmt_misc/sbox-mips enabled interpreter /scratchbox/tools/bin/misc_runner flags: P offset 0 magic 7f454c4600020008 mask 00ff Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
Re: [Scratchbox-users] New user asks for guidance
Le Tue, 9 Sep 2008 09:57:53 -0500, "Jeffrey L. Franks" <[EMAIL PROTECTED]> a écrit : > Anyone have some opinions regarding this approach and how to make it > work, what to watch out for? How hard is this going to be? As far as I've understood, and my experiments tend to confirm this, the toolchain must have been generated in a /scratchbox/compilers/ directory in order to be integrated into Scratchbox. Moreover, the toolchain must be compiled against the Scratchbox environment, notably the libc. So, I'd say that what you want to do (integrate an already existing binary toolchain in Scratchbox) is not possible. But I'm far from being a Scratchbox and toolchain expert, though. Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com ___ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
[Scratchbox-users] Integrated toolchain doesn't look in standard library directories
Hi,
[ I'm resending this e-mail that I already sent to the list on
September, 5th, but that never made it to the list for some reason. ]
I tried to integrate an ARM and MIPS toolchain, generated by Buildroot,
into Scratchbox using sb-toolchain-extras. These toolchains have been
successfully integrated, and they are able to generate binaries that
can be transparently executed by Scratchbox.
However, at the link step, they don't look in /usr/lib
or /usr/local/lib for libraries:
===
[sbox-mipsdemo: ~/mips] > cat hello.c
#include
int main(void)
{
printf("Hello World\n");
return 0;
}
[sbox-mipsdemo: ~/mips] > gcc -o hello hello.c
[sbox-mipsdemo: ~/mips] > ./hello
Hello World
[sbox-mipsdemo: ~/mips] > ls -l /usr/lib/libz.a
-rwxr-xr-x 1 thomas thomas 106316 Sep 4 16:55 /usr/lib/libz.a
[sbox-mipsdemo: ~/mips] > gcc -o hello hello.c -lz
/scratchbox/compilers/mips-linux-gcc-4.2.4-uclibc-0.9.29/usr/bin/../lib/gcc/mips-linux-uclibc/4.2.4/../../../../mips-linux-uclibc/bin/ld:
cannot find -lz
collect2: ld returned 1 exit status
[sbox-mipsdemo: ~/mips] > gcc -o hello hello.c -lz -L/usr/lib
[sbox-mipsdemo: ~/mips] >
===
The same test case works with the ARM toolchain officially provided by
Scratchbox.
My toolchain has been directly generated
in /scratchbox/compilers/, as recommended by the documentation.
I've been told on IRC that it could be a problem in the gcc spec file,
but it correctly sets cross_compile to 0, which should tell the
compiler to act as a native compiler and look in /usr/lib
and /usr/local/lib.
I have both a MIPS toolchain and an ARM toolchain generated by
Buildroot. The MIPS toolchain has been generated recently, while the
ARM toolchain has been generated months ago (I just reinstalled
the .deb I had). And I *think* the ARM toolchain was working properly
at that time. So, I have the feeling that the problem might not be in
the toolchain, but rather in the environment.
Do you have any idea of what could be the source of this problem ?
If anyone wants to test the toolchain, it is available for download at
http://toulibre.org/~thomas/scratchbox/scratchbox-mips-linux-gcc-4.2.4-uclibc-0.9.29_1.0.10_i386.deb
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
___
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
