On 09/10/2012 09:30 PM, Max E. Reyes Vera J. wrote:
I'm trying to run sb2-init but I'm getting the error:
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
You're compiling libtool whilst creating a
On 04/05/2012 11:26 AM, Athanasios Silis wrote:
my sbox has an arguably very old toolchain. here/s the info:
[sbox-sbc26: ~] sb-conf sh
Compiler: arm-linux-gcc3.4.cs-glibc2.3
Devkits: perl autotools-legacy git python-legacy qemu svn debian-squeeze
CPU-transparency:
On 04/05/2012 04:01 PM, Athanasios Silis wrote:
what files do you think are missing? cause after I completed your
sb-conf steps, i get pretty much the same output as before:
I was thinking you're missing the base etc files, and files related the
debian infrastructure.
you probably meant
On 03/28/2012 03:02 PM, James Brown wrote:
Thanks for your answer. It is very pitty.
Indeed it is.
Some of the packages are still generated inside Scratchbox itself. It
could do with an upgrade to the packaging tools.
After that, it would probably be reasonable at one point to have better,
On 03/24/2012 08:59 PM, James Brown wrote:
I cannot find signatures on the web-pages of scratchbox-project which
used for signing the packages from ist repos.
Are their exist?
There are none.
The repository is not signed.
Regards,
Jussi
___
New releases:
=
* scratchbox-core 1.0.27
* scratchbox-libs 1.0.27
* scratchbox-toolchain-host-gcc 1.0.27
Highlights:
===
* Support for /run on systems that have it
* Debian: more careful with bindmounts when uninstalling (#330)
* Faster upgrades from previous versions if
On 01/18/2012 04:58 PM, Adam Magaluk wrote:
What is the best way to share a folder available on the host system to
the scratchbox environment when I run /scratchbox/login
If you want just to temporarily move files, /tmp is the same in and
outside scratchbox.
Currently I keep having to copy
On 12/14/2011 02:40 PM, Guillermo Rodriguez Garcia wrote:
I am trying to use scratchbox to compile code for an armv4t target.
However the available ARM toolchains seem to be ignoring the -march
option, hence generating code that will not run on the target device.
I have installed the latest
On 12/07/2011 05:06 PM, Adam Magaluk wrote:
I figured it was something to do with that, Im just not
very knowledgeable on how exactly binfmt_misc works.
Any ideas on how I could get both of my development strategies working?
Well, the easiest way is to set qemu-arm from your host once again
On 12/07/2011 01:54 AM, Adam Magaluk wrote:
Finally I normally run to chroot into my newly created arm emdebian system.
sudo chroot EmDebian /
But as soon as I install scratchbox-core I get the following error
on sudo chroot EmDebian
chroot: failed to run command `/bin/bash': No such
On 10/18/2011 02:05 AM, Antoine Bouthors wrote:
I'm trying to setup scratchbox to cross-compile for an ARM target. I got
scratchbox setup and got past the helloworld examples and qemu, and now
I would like to try sbrsh.
I have installed sbrshd on the device and sbrsh on the host, and it all
On 10/11/2011 02:32 AM, Kristen Eisenberg wrote:
New releases:
=
* scratchbox-core 1.0.23
* scratchbox-libs 1.0.23
* scratchbox-toolchain-host-gcc 1.0.23
* scratchbox-devkit-debian-squeeze 1.0.7
Please refrain from reposting old release notes in the mailing list.
Regards,
On 09/07/2011 12:55 PM, Athanasios Silis wrote:
I shall continue with some questions if I may :) ... please!
is info about the instruction set stored in an executable? ie can i
verify the version of the arch of an executable, just as I can find out
the arch using the command 'file' ?
You might
On 09/06/2011 02:01 PM, Athanasios Silis wrote:
Then I guess its the
scratchbox-toolchain-arm-linux-cs2010q1-202-1.0.17-2-i386.tar.gz the
toolchain I will need..? where can I read info about the specific toolchain?
The compiler will tell how it was configured if you issue a command like
gcc
On 09/06/2011 05:22 PM, Athanasios Silis wrote:
I have managed to setup a target with:
Issuing sb-conf show without arguments will give you complete output :)
the arch as i see from gcc -v is --with-arch=armv5te
which is not suitable for me, i am attempting to get the older
codesourcery
On 09/01/2011 07:11 PM, tgrs tfyguhi wrote:
After a little more investigation, it appears that it appends only with
the target arm-linux-cs2010q1-202. I deleted and recreated the target,
just to be sure, but that was not the problem.
Can you give me the output of sb-conf show on that target?
On 08/31/2011 07:03 PM, tgrs tfyguhi wrote:
But the binary is NOT the same if I use 'gcc' provided by the target, or
if I directly use
/scratchbox/compilers/arm-linux-cs2010q1-202/bin/arm-none-linux-gnueabi-gcc.
(If I understand properly how Scratchbox works, it's supposed to be the
same gcc)
On 07/03/2011 01:25 AM, Ron Hermsen wrote:
I tried to install the same setup as I did a year ago (SB1.0.17), and
each time I try to setup the new target I get: Failed to install
C-libraty to tarket: DV20x0
I even re-installed everything from scratch twice, but same results.
(Using the current
On 07/03/2011 01:25 AM, Ron Hermsen wrote:
python-host ~/sb-toolchain-extras/confhelper/create_toolchain_conf.py
is working.
... and that's the preferred way of using it.
Changing the interpreter explicitly to python-host would make the script
executable only from within scratchbox.
On 06/22/2011 08:05 PM, Ron Hermsen wrote:
The wiki is asking for “scratchbox-devkit-cputransp”, but this is
missing in the Hathor download directory [2].
What is the solution for this?
The wiki is quite outdated.
You want to install scratchbox-devkit-qemu instead, unless you
explicitly
New releases:
=
* scratchbox-core 1.0.26
* scratchbox-libs 1.0.26
* scratchbox-toolchain-* 1.0.26
Highlights:
===
* Fix an issue with unnecessary warning when umounting bindmounts
on recent linux distributions
Notes:
==
* Hathor r1 wiki page [1] contains the
New releases:
=
* scratchbox-core 1.0.25
* scratchbox-libs 1.0.25
* scratchbox-toolchain-host-gcc 1.0.25
* scratchbox-devkit-qemu 0.13.90-0rabbit1
* scratchbox-toolchain-* 1.0.24
Highlights:
===
* Qemu 0.13
* Various minor fixes both on scratchbox and the toolchain
On 05/12/2011 05:00 AM, Diane Holt wrote:
Did you post your linaro on the downloads page? (All I see are ones
named cs*, which I assume are CodeSourcery ones.)
Did not, I've recompiled the toolchain and added 2 patches so it's not
exactly official linaro one :)
However, if you want to try
On 05/12/2011 07:06 PM, Diane Holt wrote:
Just FYI, I found the error. The make process requires the C++ headers
be at /scratchbox/compilers//compiler-name//include/c++ -- mine were at
/scratchbox/compilers//compiler-name//arm-linux-gnueabi/include/c++.
It didn't complain about missing headers
On 03/12/2011 01:00 AM, Diane Holt wrote:
Is there any chance that the host_shared libc will ever be updated?
As far as I know, there's no plans at least from the usual parties
that've been sponsoring scratchbox development.
If not officially, is there a way a person could do it for
New releases:
=
* scratchbox-core 1.0.24
* scratchbox-libs 1.0.24
* scratchbox-toolchain-host-gcc 1.0.24
* scratchbox-devkit-python-legacy 1.0.2
Highlights:
===
* /usr/bin/python is no longer provided by scratchbox, you can
find the built-in python as python-host. Select
On 08/25/2010 03:46 PM, Antoni Silvestre Padrós wrote:
Hi, I've compiled a foreign toochain and was about to setup my target
with sbrsh but when I get to the transparency method screen of the
sb-menu command there is no sbrsh option.
Do you have cputransp devkit installed and selected for your
On 09/02/2010 09:45 AM, chao yu wrote:
My target CPU is s3c2440 which is arm v4t architecture and I want
to compile a executeable binary to run on it. I added the parameter
-march=armv4t and built. But I found before link, the object file is
armv4t. After link stage, the generated file is
On 06/12/2010 12:02 AM, Diane Holt wrote:
What about vm.mmap_min_addr -- does that still need tweaking, or is that
corrected as well?
That was strictly a qemu related issue which hasn't been present for a
while in the new qemu devkits.
However, there was a kernel version which had a clever
On 06/09/2010 12:05 PM, Raghavendra. S wrote:
Please let me know what all things I should edit for my compiler. I am
getting above error. Please let me know why this error is accuring.
There's already a scratchboxified version available from that compiler
in the Hathor repository [1].
Check
On 06/09/2010 12:06 PM, Raghavendra. S wrote:
Hi All,
I am getting error while adding foreign tool chain.
# cd /scratchbox/sb-toolchain-extras/
# make CONFIG=meta/alien-tc/arm-none-linux-gnueabi.conf -C
Why is your sb-toolchain-extras repository located in the top level of
scratchbox
On 06/09/2010 01:33 PM, Raghavendra. S wrote:
I saw that in some forum's they mentioned about
/scratchbox/device_tools.
In the stable branch the device tools come from toolchain extras.
The part you're referring to might be the device_tools from the old
toolchains repo, from the time
Scratchbox Hathor is now the latest release of the stable branch. Hathor
will be the successor of Apophis.
Since the releases are of the same stable branch most packages are
usable as-is on the new scratchbox, although it's recommended to use
packages only from the Hathor release if they're
Mika Westerberg wrote:
That wiki page is for sb1 and seems to be outdated as mmap_min_addr setting is
not needed anymore (QEMU handles this automatically).
Yes, new qemu versions handle that automatically.
However, for sb1 you need to use qemu devkit, cputransp devkit contains
older version
Aaron Brice wrote:
I'm on a RHEL 5 host system, using scratchbox2 and the latest 4.4
CodeSourcery IA32 toolchain. It seems like it's linking against the
host system ancient glibc (libc-2.5.so) instead of the toolchain's
glibc (libc-2.10.1.so):
You are building the kernel inside scratchbox?
New releases:
=
* scratchbox-devkit-debian-squeeze 1.0.3
Highlights:
===
* Fixed the issue with missing perl library on certain perl
based scripts
* Fixed the issue of install-info busylooping, when a certain version
of install-info installed on target
Notes:
==
*
New releases:
=
* scratchbox-toolchain-cs2007q3-glibc2.5-arm7
* scratchbox-toolchain-cs2007q3-glibc2.5-i486
Highlights:
===
* Recompiled the toolchains to include fix for dwarf2out-pr31899
http://gcc.gnu.org/bugzilla/attachment.cgi?id=14286
* Added a separate changelog
New releases:
=
* scratchbox-devkit-debian-squeeze 1.0
Highlights:
===
* New, minimal devkit containing squeeze versions of debian tools
Software changes:
=
* debian-squeeze
* New
* apt
* debhelper
* debianutils
* dpkg
Notes:
==
*
Scratchbox's host compiler is old. As is the glibc...
Part of the reason is the somewhat improper way it's built, the whole
core set of tools should be upgraded to a modern era but that's quite a
bit of work.
Regards,
Jussi
Rasjid Wilcox wrote:
New to scratchbox. I'm compiling a number
Kartik Natarajan wrote:
No package 'glib-2.0' found
I have tried everything I could possibly do, I have libglib2.0-dev
installed on my system. Please help.
System meaning your host system?
You need to have it compiled and installed to your target. When you
login to scratchbox, you're
Enrique Poves wrote:
Solved. It was just a problem with my Antivirus sw.
# file Packages.gz
Packages.gz: ASCII English text
Anybody can give a clue about what's going on?
Apparently your antivirus extracted the archive to see if it contained
anything malicious :P
The original file is as
For basic scratchbox setup, grab core, libs and a set of
devkits/toolchains of your choice.
The issue you're having is due to old host-side glibc inside scratchbox
that can be circumvented with [1]. See also [2] for further known issues.
Regards,
Jussi
[1]
echo 0 | sudo tee
New releases:
=
* scratchbox-toolchain-cs2007q3-glibc2.5-arm6
* scratchbox-toolchain-cs2007q3-glibc2.5-arm7
* scratchbox-toolchain-cs2007q3-glibc2.5-i486
Highlights:
===
* Recompiled the toolchains to include eventfd support
(taken from eglibc 2.9)
* Add -mfpu=neon
New releases:
=
* scratchbox-devkit-apt-https 1.0.9
Highlights:
===
* Fixed the issues with extra long dependecy fields
Notes:
==
* Apophis R4 wiki page [1] contains the information on known issues
and other release specific things.
Report bugs to scratchbox.org
New releases:
=
* scratchbox-devkit-doctools 1.0.12
* scratchbox-toolchain-cs2007q3-glibc2.5-arm6
* scratchbox-toolchain-cs2007q3-glibc2.5-arm7
* scratchbox-toolchain-cs2007q3-glibc2.5-i486
Highlights:
===
* Recompiled the toolchains to include another profiling fix for arm
New releases:
=
* scratchbox-devkit-apt-https 1.0.7
Highlights:
===
* Apt no longer defaults to install recommended packages
* Fixed an issue with leftover development files sometimes
contaminating the build process inside scratchbox
* Reverted upstream patch which caused
New releases:
=
* scratchbox-toolchain-cs2007q3-glibc2.5-arm6 1.0.11-7
* scratchbox-toolchain-cs2007q3-glibc2.5-arm7 1.0.11-8
* scratchbox-toolchain-cs2007q3-glibc2.5-i486 1.0.11-6
Highlights:
===
* Recompiled the toolchains to include profiling fix for arm [1]
(requires
New releases:
=
* scratchbox-core 1.0.14
* scratchbox-libs 1.0.14
* scratchbox-toolchain-host 1.0.14
* scratchbox-devkit-apt-https 1.0.5
* scratchbox-devkit-doctools 1.0.11
* scratchbox-devkit-qemu 0.10.0-0sb5
Highlights:
===
* New, independent qemu devkit containing
Eade, Sean (SCR US) wrote:
I have been trying to follow this tutorial, to use the scratchbox:
http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/installdoc.html
That tutorial maybe sadly a bit out of date.
But I can’t find the toolchain
New releases:
=
* scratchbox-devkit-doctools 1.0.10
* scratchbox-toolchain-arm-linux-cs2007q1-21sb1 1.0.9
* scratchbox-toolchain-arm-linux-cs2007q3-51sb3 1.0.9
Highlights:
===
* 2 CS toolchains previously packages only unofficially have now
been repackaged and made
Probably you have no locate db in your target.
Additionally I'm unsure anyone's actually using Scratchbox's locate and
how well it works in general.
You can probably find the directory in /usr/lib/pkgconfig and/or
/usr/share/pkgconfig.
Regards,
Jussi
surabhi dwivedi wrote:
Hello
I'd suggest using the latest release unless you have a reason to use
that particular version.
However, older releases can be found in [1].
Regards,
Jussi
[1] http://scratchbox.org/download/files/sbox-releases/branches/
Ville Hyttinen wrote:
I'm following the instructions on web page
Also in the scratchbox.org wiki, Apophis R4 page, listed under known
issues :)
http://scratchbox.org/wiki/Apophis-r4
Regards,
Jussi
Kalle Vahlman wrote:
2008/12/23 vandy linux vandy.li...@gmail.com:
I am using cpu transparency as u told , getting errors then also, I am
attaching the
Velikanov, Mikhail wrote:
However, I'm beginning to think that the most sensible plan would be
just to upgrade the host-side glibc to a less ancient level.
This won't really prevent this problem from happening, although it'll
probably make it more rare. There is always a chance someone might
Or you can try to copy the binary (and additional libraries it needs)
under /host_usr/, in most of the cases, that works too.
Or, you can use a statically linked binary...
Regards,
Jussi
Diane Holt wrote:
You can run statically linked executables inside Scratchbox that were
built outside
holger krekel wrote:
i am currently experimenting with cross-compilation of large
C-files. For this, i need to use the cross-compiler from the
hosting end because compiling in the virtual environment takes
around 10 times as long (but succeeds). If i follow the 1.0
tutorial and use the
The scratchbox.org bugzilla is now finally back online.
Sorry about the delay, it's been a huge mess with hosting issues,
hopefully everything is now sorted and we can get back to business as
normal.
In the progress the debian system running in the server was upgraded
closer to present
New releases:
=
* scratchbox-core 1.0.11
* scratchbox-libs 1.0.11
* scratchbox-toolchain-host-gcc 1.0.11
* scratchbox-devkit-git 1.0.1 [1]
* scratchbox-devkit-svn 1.0 [1]
Highlights:
===
* In the interest that debug symbols are actually found,
added new option to install
New releases:
=
* scratchbox-toolchain-cs2007q3-glibc2.5-arm6 1.0.8-5
* scratchbox-toolchain-cs2007q3-glibc2.5-arm7 1.0.8-6
* scratchbox-toolchain-cs2007q3-glibc2.5-i486 1.0.8-3
Highlights:
===
* Recompiled the toolchain with the following patches:
* fix for the issue
Daniel Bainton wrote:
If that's the case, we have to fix it...
Just do a echo $PATH in SB. I doubt /host_usr is before the devkits
and core for you either. Isn't there a bug for this? Atleast it's been
mentioned in IRC... :)
Fixed in the vcs head.
Yeah, the bugzilla is still offline...
Thomas Petazzoni wrote:
As far as I've understood, and my experiments tend to confirm this, the
toolchain must have been generated in a /scratchbox/compilers/foo
directory in order to be integrated into Scratchbox. Moreover, the
toolchain must be compiled against the Scratchbox environment,
Thomas Petazzoni wrote:
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
Daniel Bainton wrote:
That, or you can do as Kalle suggested and compile a newer version of python
for the host architecture and put it inside /host_usr/. After that you won't
need any environment variables since stuff in /host_usr/ always override the
stuff in devkits and the core.
That is,
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
Indeed. It would seem that the problem of selecting compat vdso support
from the proc filesystem affects mostly 64 bit stock kernels.
Regards,
Jussi
Graham Cobb wrote:
By the way, if you are running a 64-bit kernel then
the /proc/sys/vm/vdso_enabled file will not exist and the only option
And, if you want, you can do additional bindmounts outside scratchbox as
well (you have to be root to do those). Do note that stopping scratchbox
with sbox_ctl will remove the scratchbox provided bindmounts but will
not touch any additional mount you have created. Make sure you umount
all
Ian Burrell wrote:
No. Fedora 9 is using 2.6.25 (latest is 2.6.25.10-86.fc9). As I
said, the kernel is compiled without CONFIG_COMPAT_VDSO. It looks
like this causes the /proc/sys/vm/vdso_enabled file to not exist. My
impression is that the kernel config is a result of using
Ray Kiddy wrote:
I started with the
present http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/installdoc.html
and added info to the wiki pages
at http://www.scratchbox.org/wiki/ScratchboxInstallation
and http://www.scratchbox.org/wiki/ScratchboxTargetConfiguration. A lot
of
Ian Burrell wrote:
I am unable to get scratchbox (for Maemo 4.1 SDK) working on Fedora 9.
I saw lots of places talking about disabling VDSO. The problem is
that Fedora 9 does not have /proc/sys/vm/vdso_enabled file. It looks
like the kernel is configured without compat VDSO support.
Indeed.
This is a qemu problem.
The version of qemu you're using cannot run the binaries produced by
your toolchain. This makes your configure to fail too as it just tries
to run the compiled test program and will stop whenever the compiled
binary exits with a code other than 0.
Regards,
Jussi
:26:24 am Jussi Hakala wrote:
E Robertson wrote:
I get this when I run that comand:
sb-conf: No fakeroot versions found for compiler: host-gcc
Ah, yes.
I don't know what I was thinking when I wrote that, sorry :)
Is the error message the same if you try to run anything else under
fakeroot
E Robertson wrote:
I get this when I run that comand:
sb-conf: No fakeroot versions found for compiler: host-gcc
Ah, yes.
I don't know what I was thinking when I wrote that, sorry :)
Is the error message the same if you try to run anything else under
fakeroot, for example:
$ fakeroot ls
The most reliable thing would be probably to test the presence of a
scratchbox-like directory layout [1] or if env output contains any SBOX_
prefixed variables [2] (but this may lead to ambiguity between sb1 and sb2).
Regards,
Jussi
[1]
if [ -e /targets/links/scratchbox.config ] ; then
Interesting error.
Try [1], and see if that solves your problem.
Regards,
Jussi
[1] sb-conf in HOST -F
E Robertson wrote:
Hi All,
I'm attempting to use a foreign toolchain and I seem to be stuck at
building the auxiliary tools. I followed all the instructions so far,
and unless I'm
New release:
* scratchbox-devkit-maemo3 1.0.3
Highlights:
* Etch version of openssl, complete with fixes for
the randomness issue
* Fixed an issue with quilt and missing files
Report bugs to scratchbox.org bugzilla.
Happy hacking,
Jussi
___
You can compile a custom uclic toolchain using buildroot and then
compile the sb-toolchain-extras package [1] on top of that. That should
provide you with a proper sboxified uclibc toolchain with the options
you want.
[1] http://scratchbox.org/wiki/ForeignToolchains
Regards,
Jussi
J
New release:
* scratchbox-devkit-cputransp 1.0.6
Highlights:
* Fixes an issue with qemu-arm-cvs-m and dynamic loading of
libraries failing with cannot enable executable stack
Report bugs to scratchbox.org bugzilla.
Happy hacking,
Jussi
___
-Marie
*
*
Jussi Hakala wrote:
If you have already a cross toolchain, you can import it inside
scratchbox using the instructions in scratchbox.org wiki [1].
Otherwise you have to first compile a crosstoolchain for yourself, the
oldest toolchains available at scratchbox.org are gcc 3.3
If you have already a cross toolchain, you can import it inside
scratchbox using the instructions in scratchbox.org wiki [1].
Otherwise you have to first compile a crosstoolchain for yourself, the
oldest toolchains available at scratchbox.org are gcc 3.3/glibc 2.3.
Regards,
Jussi
[1]
New release:
* scratchbox-devkit-doctools 1.0.8
Highlights:
* Debian packages contain an actual changelog based on
the version control history
* Catalogs are now copied to (and accessed from) the target
* Removed *-config binaries from host side
* Fixed a number of smaller issues with
Hi,
Peter already gave the urls for the information in wiki.
There's also a pre-built package of the toolchain you're using available
in [1]. Give that a try if you don't want to compile the extras on top
of the binary package yourself...
The sb1 version differs only with respect to specs,
What does gcc -dumpmachine report for your compiler?
In the package you are building the compiler is specified manually with
CC=arm-linux-gnu-gcc. You can change this from debian/rules.
Regards,
Jussi
Trilok Soni wrote:
Hi,
I am trying to import crosstool built foreign toolchain into
Provided that your scratchbox is installed in /scratchbox (or you have
symlink there), you should be able to use the scratchbox compilers from
outside scratchbox (for example, to compile the kernel) as well [1].
Depending on your package you might have to specify CC in your
environment or
It's not about Scratchbox version. It's about the toolchain you're using.
You need to compile sbrshd against the libc you have in your target. You
can compile the package in the device itself, or try to find a toolchain
supporting your c-library and compile it inside Scratchbox.
There are
The apt-https devkit has now a version 1.0.3. There's nothing new with
the 1.0 released a couple of days ago, but it addresses the fact that
previously there was a devkit with the same name with a version number
1.0.2.
Since the apt-https devkit released a couple of days ago is a complete
And with the reference:
[1] sb-conf in -d
Jussi Hakala wrote:
You mean /var/lib/dpkg doesn't exist in your target?
If that's the case, [1] should solve your problem.
Regards,
Jussi
Peter Pearse wrote:
Hi
When building Debian packages in scratchbox I often get problems
because
Timo Savola wrote:
Thanks! I had actually just tracked down misc_runner, so I was starting to
look at misc_runner.c myself, but if the fix will be available soon, I guess
I can stop doing that :)
BTW, I tried passing the flag in using the var, but it didn't work.
It should.. Anyway, my
If you're developing for maemo, the glib and gtk packages can be found
maemo.org repositories.
Are you sure you have the packages installed in your target? The pc
files (which you are probably missing, if i understood the nature of
your problem correctly) can be found in the -dev package.
The qemu you're using does not handle binaries your toolchain is
producing. You could try the cvs version of qemu available in the
development snapshot of cputransp package in [1].
Regards,
Jussi
[1] http://scratchbox.org/~jhakala/unofficial/
Mickael Istria wrote:
Hello,
I succeded to
The debian repositories at scratchbox.org have been restructured.
Use [1] for the latest stable packages of scratchbox. Use [2] for the
latest legacy packages of scratchbox. For a specific release, use
complete release name instead of stable/legacy, for example [3] and [4].
For latest
Additional upgrades to Scratchbox Apophis R4 have been released:
* scratchbox-devkit-doctools 1.0.6
* scratchbox-devkit-debian 1.0.8
And a completely new devkit:
* scratchbox-devkit-maemo3
The new debian devkit brings etch tools to Scratchbox and some
significant architectural changes:
*
Issues with the Debian devkit 1.0.7 have been fixed.
Please update your Debian devkit to 1.0.7.1, if you have previously
installed the 1.0.7 version. The old version is no longer available.
See [1] for details.
[1] http://scratchbox.org/
Regards,
Jussi
A prepackaged version latest Codesourcery toolchain is now available at
scratchbox.org.
Downloads from Apophis release page, [1].
[1] http://scratchbox.org/download/scratchbox-apophis/
Regards,
Jussi
___
Scratchbox-users mailing list
The spoofing works with files located in deb_list directories.
Unfortunately, these directories are not seen by apt or even dpkg.
They're only seen by dpkg-checkbuilddeps.
Go with Riku's suggestions.
If you want to spoof anything other (in the target), create a dummy
package and install it.
Your toolchain's architecture is arm, so you'll have to choose arm
instead of armeb. As a rule of thumb, it's wise to choose the latest
qemu version.
The sb2 stands for the patchset applied to that version of qemu. The
m2 is slightly different patchset, but it is very unlikely in your
case
Michael Burian wrote:
http://www.scratchbox.org/wiki/ForeignToolchains
in section Configuring
cite
1. Setup the system as in building native Toolchains (Compiling
toolchains, steps 1-3), with exception that you must have perl and
doctools devkits selected as well
/cite
As the link points
The sb-menu and sb-conf tools are exclusive to Scratchbox 1.0 (and
Apophis) branches.
In the legacy branch (pre-1.0), sbox-config is used.
The Apophis r4 release includes a support for legacy toolchains (in
addition to repackaged Apophis versions of those toolchains). If you
want to avoid the
New versions of the repackaged legacy toolchains have been released.
These packages contain updated versions of libtool and gdb. More
information and downloads from http://scratchbox.org.
Regards,
Jussi
___
Scratchbox-users mailing list
You should not use cs2005q3.2-glibc-arm unless you need that specific
toolchain. It's repackaged version of legacy branch toolchain. Use
arm-linux-cs344-2.3 instead.
Does the arm-linux-cs344-2.3 work for you from earlier installations? If
you try packages from [1], for example.
[1]
Inside Scratchbox, your target's rootfs is located in
/targets/${TARGET_NAME}.
You could make the debootstrap outside scratchbox, make a tarball of the
debootstrapped rootfs and extract it into the target using sb-menu or
sb-conf (or alternatively by copying the files by hand).
Regards,
Jussi
1 - 100 of 117 matches
Mail list logo
