|
List Info
Thread: Notes on building crosstool compilers and crocodile packages for powerpc (PPC) using scratchbox
|
|
| Notes on building crosstool compilers
and crocodile packages for powerpc (PPC)
using scratchbox |

|
2006-12-21 16:41:30 |
Since I've been recently coming up the learning curve, I
thought to copy
some of my notes here in the hope that they might help some
people.
This covers building your own foreign toolchain and then
install that in
scratchbox to build crocodile packages for powerpc.
Here are some notes. I was working on two different
toolchains (ppc603
and ppc860), so I refer to both interchangably. There may
be some
omissions or errors, it's a work in progress. There are two
patches
that were needed to build the crocodile packages for
powerpc, one for
procps and one for zlib.
-Jim Heck
**0. Starting with a vanilla Ubuntu 6.10 installation. I
tried this
because I had problems installing scratchbox 1.0.6 on Debian
(turns out
Debian was fine, as I was able to install on my laptop
running Debian).
The installation hung in the stage where it was running the
preinstall
scripts for the packages. This may have had something to do
with
autofs, since the installation creates an sbox user. I
confirmed that
scratchbox installs on Debian if autofs is not used.
**1. Installed scratchbox-core (1.0.7). This pulled in
scratchbox-libs
(1.0.7). Ultimately I ended up installing the following
scratchbox
packages.
--------------------------------------
jheck ubuntu-cross:/scratchbox/users/jheck/home/jheck/croco
dile/patches$
dpkg -l |grep scratchbox
ii scratchbox-core
1.0.7 Scratchbox base system
ii scratchbox-devkit-cputransp
1.0.1 CPU transparency methods
ii scratchbox-devkit-debian
1.0.6 Debian tools for Scratchbox
ii scratchbox-devkit-doctools
1.0.5 Doctools for Scratchbox
ii scratchbox-devkit-perl
1.0.4 Perl modules for Scratchbox
ii scratchbox-libs
1.0.7 Scratchbox libraries
ii scratchbox-toolchain-arm-linux-ct401-2.3
1.0.4 arm-linux-ct401-2.3 compiler
for Scratchbox
ii scratchbox-toolchain-host-gcc
1.0.7 Scratchbox host-gcc toolchain
ii scratchbox-toolchain-i686-gcc3.3-glibc2.3
1.0.3 i686-linux-gcc3.3-glibc2.3
compiler for Scra
**2. Decided to start by trying to install a foreign
toolchain (see
1).
To prepare for this, I built a few toolchains using
crosstool 0.42
from Dan Kegel (see 2).
See the following web pages:
1 http
://www.scratchbox.org/wiki/ForeignToolchains
- overview of foreign toolchains for scratchbox
2 http://kegel.com/crosstoo
l/
- overview of crosstool
3
http://kegel.com/crosstool/crosstool-0.42/buildlogs/
- summary of working crosstool combinations
4 http://kegel.com/crosstool/crosstool-0.42/doc/
crosstool-howto.html
- crosstool step by step howto
**2.1 Used a supported combination of glibc and gcc under
crosstool 0.42
to make a compiler. I built this as user jheck under
/home/jheck and
targeted /opt/crosstool/ for the built compiler
- gcc-3.4.5
- glibc-2.3.6
**2.2 Here is a cat of the configuration file used
/home/jheck/crosstool-0.42/demo-ppc603.sh
--------------------------------------
#!/bin/sh
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to
run as root.
mkdir -p $RESULT_TOP
# Build the toolchain. Takes a couple hours and a couple
gigabytes.
#eval `cat powerpc-603.dat gcc-3.4.0-glibc-2.3.2.dat` sh
all.sh
--builduserland --notest
# eval `cat powerpc-603.dat gcc-3.4.1-glibc-2.3.3.dat` sh
all.sh --notest
#eval `cat powerpc-603.dat gcc-3.4.1-glibc-20040827.dat` sh
all.sh --notest
eval `cat powerpc-603.dat gcc-3.4.5-glibc-2.3.6.dat` sh
all.sh --notest
#eval `cat powerpc-603.dat gcc-3.4.5-glibc-2.3.6.dat` sh
all.sh
--nounpack --notest
echo Done.
--------------------------------------
**2.3 Had the following problems compliling the toolchain
- libc6-dev was not installed by Ubuntu by default and had
to be added
- /bin/sh was linked to the /bin/dash shell and that caused
problems.
Solved by changing it to link to /bin/bash.
**2.4 Resulting toolchain was functional, but had a
dependence on the
host glibc, which was version 2.4 based. This toolchain
would not work
in scratchbox, since scratchbox only includes a 2.3 based
version of
glibc for the host crosscompiler to use. The fix for this
was to
compile the crosstool toolchain under scratchbox (see 3.)
**3. Rebuilt the crosstool 0.42 toolchain under scratchbox.
The steps
are outlined below. Basically I built in my home directory
targeting
/opt/crosstool.
NOTE: This must NOT be done using the scratchbox HOST
sandbox, since
doing so will result in a compiler with a ld that does not
look for
library dependencies in /usr/lib. Instead you must use a
scratchbox x86
toolchain. I was not able to find or build one using the
latest Apophis
r4 version, so I went back and grabbed a toolchain from
Apophis r3
(scratchbox-toolchain-i686-gcc3.3-glibc2.3_1.0.3_i386.deb).
I made a
sandbox using this toolchain and the debian devkit, and
compiled the
crosstool toolchain.
See the following web pages:
http://scratchbox.org/download/files/
sbox-releases/branches/apophis/r3/deb/
--------------------------------------
as user jheck
$ /scratchbox/login
[sbox-ct-compile: ~] >export
http_proxy=xxx.xxx.xxx.xxx xxx
[sbox-ct-compile: ~] >export
ftp_proxy=xxx.xxx.xxx.xxx xxx
- to get past the firewall, setup proxies so other tools can
work
[sbox-ct-compile: ~] >wget http
://kegel.com/crosstool/crosstool-0.42.tar.gz
[sbox-ct-compile: ~] >tar xvzf crosstool-0.42.tar.gz
[sbox-ct-compile: ~] >cd crosstool-0.42
- get the croostool tarball
[sbox-ct-compile: ~] >cp demo-ppc604.sh demo-ppc603.sh
[sbox-ct-compile: ~] >vi demo-ppc603.sh
- setup the master 'demo' script to build
glibc-2.3.6/gcc-3.4.5 toolchain
- see 2.2 above for contents of demo-ppc603.sh
[sbox-ct-compile: ~] >unset LD_LIBRARY_PATH
- LD_LIBRARY_PATH cannot be set during compile, and
scratchbox has it
set, so unset it
[sbox-ct-compile: ~] >ln -sf /scratchbox/tools/bin/bash
/bin/sh
- fixinc.sh in
/home/jheck/crosstool-0.42/build/powerpc-603-linux-gnu/gcc-3
.4.5-glibc-2.3.6/build-gcc-core/gcc
needs a link to sh in /bin, so create one
[sbox-ct-compile: ~] >sh demo-ppc603.sh 2>&1 |tee
../ppc603.log
- invoke the crosstool build script, and wait
**4. Built the scratchbox sb-toolchain-extras set of tools,
to allow the
toolchain to be integrated into the scratchbox environment.
NOTE: One thing to remember here is that the toolchain has
compiled into
it, absolute paths to find its libraries and includes
(/opt/crosstool/gcc-3.4.5-glibc-2.3.6/powerpc-860-linux-gnu/
powerpc-860-linux-gnu/lib
and .../include). The scratchbox environment installs the
toolchain in
such a way that the necessary files for the compiler are
copied to well
known locations under /usr/lib and /usr/include. This is
how the
compiler will find them. A caveat to note is that this
process will
work only only for toolchains that don't mess with the
structure of the
lib and include directories. Notably, I had a problem with
the
powerpc-860 compiler, which doesn't have a floating point
unit. In this
case, a few static libraries (e.g. the libstdc++.a) were
located in a
subdirectory under the /lib directory (/lib/nof). This
caused crosstool
confusion when building the sb-toolchain-extras. I had to
manually copy
the static libraries up into the /lib directory of the built
compiler
tree so that the crosstool build/scripts could find them.
Thus the use
of the "standard" path metod crosstool employes is
a bit scary, since it
cannot know exactly how the compiler is setup, and thus we
must be
certain the compiler is working properly in the scratchbox
environment.
--------------------------------------
as user jheck logged into scratchbox
[sbox-HOST: ~] >cd /opt/crosstool/gcc-3.4.5-glibc-2.3.6
[sbox-HOST: ~] >tar cvpzf powerpc-603-linux-gnu.gz
powerpc-603-linux-gnu
[sbox-HOST: ~] >cp powerpc-603-linux-gnu.gz
/scratchbox/compilers/.
[sbox-HOST: ~] >cd /scratchbox/compilers/
[sbox-HOST: /scratchbox/compilers] >tar xvzf
powerpc-603-linux-gnu.gz
[sbox-HOST: /scratchbox/compilers] >cd
- tar up the toolchain and untar it in the
/scratchbox/compilers directory
[sbox-HOST: ~] >cd
/scratchbox/compilers/powerpc-860-linux-gnu
[sbox-HOST: /scratchbox/compilers/powerpc-860-linux-gnu]
>rm -rf distributed
- get rid of the distributed gcc compiler because it
confuses the python
script for the toolchain-extras
[sbox-HOST: /scratchbox/compilers/powerpc-860-linux-gnu]
>cd
powerpc-860-linux-gnu/lib/nof
[sbox-HOST:
/scratchbox/compilers/powerpc-860-linux-gnu/powerpc-860-linu
x-gnu/lib/nof]
>cp *.a ../.
[sbox-HOST:
/scratchbox/compilers/powerpc-860-linux-gnu/powerpc-860-linu
x-gnu/lib/nof]
>cd
- copy the static .a libraries up to the lib directory so
they can be
found when building toolchain-extras
[sbox-HOST: ~] >darcs get --set-scripts-executable
h
ttp://scratchbox.org/repos/1.0/sb-toolchain-extras
- get the darcs repository with the scratchbox toolchain
extras
[sbox-HOST: ~] >cd
/scratchbox/compilers/powerpc-860-linux-gnu
[sbox-HOST: /scratchbox/compilers/powerpc-860-linux-gnu]
>~/sb-toolchain-extras/confhelper/create_toolchain_conf.
py >
~/sb-toolchain-extras/meta/alien-tc/powerpc-860-linux-gnu.co
nf
- create the conf file to build the alien toolchain
[sbox-HOST: /scratchbox/compilers/powerpc-860-linux-gnu]
>cd
~/sb-toolchain-extras/
[sbox-HOST: ~/sb-toolchain-extras] >make
CONFIG=meta/alien-tc/powerpc-860-linux-gnu.conf -C
meta/alien-tc all-sums
[sbox-HOST: ~/sb-toolchain-extras] >make
CONFIG=meta/alien-tc/powerpc-860-linux-gnu.conf -C
meta/alien-tc
- make the alien toolchain (first the checksums and then the
toolchain
itself)
[sbox-HOST: ~/sb-toolchain-extras] >cd
[sbox-HOST: ~] >sb-menu
- make a sandbox using the new foreign toolchain
**5. Build the crocodile set of packages. These are debian
sarge
packages necessary to bootstrap a system.
NOTE: Crocodile is based off the sarge debian distribution.
For the
most part, it builds all the libraries that the
build-essential set of
packages depends on. It does leverage a bunch of tools from
the
scratchbox environment, such as those associated with the
compiler, and
some such as autoconf, debmake, flex, etc. It proceeds in a
brute force
fashion making multiple passes trying to compile all source
packages in
a repository until no progress has been made over two
passes.
See the following web pages:
http://www.s
cratchbox.org/wiki/Crocodile
http://www.
scratchbox.org/wiki/Apophis-r4
h
ttp://www.scratchbox.org/wiki/EnvironmentVariables
--------------------------------------
as user jheck
**5.1. From Scratchbox 1.0.7 on, flex is not regarded as a
provided
package when checking debian build deps. This is fixed with
the
following, performed inside scratchbox.
# mkdir /scratchbox/users/$/targets/`sb-conf
cu`_deb_list
# cat > /scratchbox/users/$/targets/`sb-conf
cu`_deb_list/flex << EOF
Source: flex
Version: 2.5.31
Binary: flex
EOF
**5.2. For powerpc, the value scratchbox returns for 'uname
-m' is
'powerpc'. This causes problems when building packages,
since the
scripts/makefiles generally expect 'ppc'. This is fixed by
setting the
'SBOX_UNAME_MACHINE' environment variable to 'ppc'
[sbox-ppc603-croc: ~] > export SBOX_UNAME_MACHINE=ppc
**5.3. Two packages required patches over and above the ones
scratchbox
had already provided. These were procps and zlib. The
patches go in
crocodile/patches
- procps required a patch to remove dependence on a header
file
/include/asm/page.h. The use of a macro for PAGE_SIZE
resolved to a
function and was being improperly used in a variable
declaration. I
took code from the latest version of the package to patch it
in the
sarge version.
cat of procps.patch
--------------------------------------
diff -Naur procps-3.2.1/proc/devname.c
procps-3.2.1-patched/proc/devname.c
--- procps-3.2.1/proc/devname.c 2004-03-17
13:43:50.000000000 -0500
+++ procps-3.2.1-patched/proc/devname.c 2006-12-13
11:38:10.366938000 -0500
 -19,10
+19,10 
#include "version.h"
#include "devname.h"
-#include <asm/page.h>
-#ifndef PAGE_SIZE
-#define PAGE_SIZE (sizeof(long)*1024)
-#endif
+// This is the buffer size for a tty name. Any path is
legal,
+// which makes PAGE_SIZE appropriate (see kernel source),
but
+// that is only 99% portable and utmp only holds 32 anyway.
+#define TTY_NAME_SIZE 128
/* Who uses what:
*
 -216,7
+216,7 
char path[32];
int count;
sprintf(path, "/proc/%d/%s", pid, name); /*
often permission denied */
- count = readlink(path,buf,PAGE_SIZE-1);
+ count = readlink(path,buf,TTY_NAME_SIZE-1);
if(count == -1) return 0;
buf[count] = ' ';
if(stat(buf, &sbuf) < 0) return 0;
 -227,7
+227,7 
/* number --> name */
unsigned dev_to_tty(char *restrict ret, unsigned chop,
dev_t dev_t_dev,
int pid, unsigned int flags) {
- static char buf[PAGE_SIZE];
+ static char buf[TTY_NAME_SIZE];
char *restrict tmp = buf;
unsigned dev = dev_t_dev;
unsigned i = 0;
--------------------------------------
- zlib attempted to create the compiler name for the CC
environment
variable using 'dpkg-architecture -qDEB_HOST_GNU_TYPE'.
This resolved
the gcc tool name to 'powerpc-linux-gnu-gcc', but scratchbox
for some
reason has the gcc compiler linked to 'powerpc-linux-gcc'.
The fix was
to patch the rules file for the sarge package using code
from the latest
version, which invokes the compiler using the environment
variable CC,
which make maps to cc, instead of trying to build up the
tool name directly.
cat of zlib.patch
--------------------------------------
diff -Naur zlib-1.2.2/debian/rules
zlib-1.2.2-patched/debian/rules
--- zlib-1.2.2/debian/rules 2006-12-13
17:13:17.807465000 -0500
+++ zlib-1.2.2-patched/debian/rules 2006-12-13
17:27:35.457286000 -0500
 -12,13
+12,20 
DEB_BUILD_GNU_SYSTEM := $(shell dpkg-architecture
-qDEB_BUILD_GNU_SYSTEM)
DEB_BUILD_GNU_TYPE=$(DEB_BUILD_GNU_CPU)-$(DEB_BUILD_GNU_SYS
TEM)
DEB_HOST_ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
-DEB_HOST_GNU_CPU=$(shell dpkg-architecture
-qDEB_BUILD_GNU_CPU)
-DEB_HOST_GNU_SYSTEM=$(shell dpkg-architecture
-qDEB_BUILD_GNU_SYSTEM)
-DEB_HOST_GNU_TYPE=$(shell dpkg-architecture
-qDEB_BUILD_GNU_TYPE)
+DEB_HOST_GNU_CPU=$(shell dpkg-architecture
-qDEB_HOST_GNU_CPU)
+DEB_HOST_GNU_SYSTEM=$(shell dpkg-architecture
-qDEB_HOST_GNU_SYSTEM)
+DEB_HOST_GNU_TYPE=$(shell dpkg-architecture
-qDEB_HOST_GNU_TYPE)
DH_OPTIONS=
ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
TESTS=test
+CC=gcc
+CC32=gcc -m32
+CC64=gcc -m64
+else
+CC=$(DEB_HOST_GNU_TYPE)-gcc
+CC32=$(DEB_HOST_GNU_TYPE)-gcc -m32
+CC64=$(DEB_HOST_GNU_TYPE)-gcc -m64
endif
COMPAT-ARCHS=
 -58,14
+65,14 
build: $(STAMP_DIR)/build
$(STAMP_DIR)/build: $(STAMP_DIR)/source.make
$(DOBUILDCOMPAT)
dh_testdir
- cd $(BUILD_TREE) &&
CC=$(DEB_HOST_GNU_TYPE)-gcc CFLAGS="-O3 -g
-D_REENTRANT -fPIC" ./configure --shared
+ cd $(BUILD_TREE) && CC=$(CC)
CFLAGS="-O3 -g -D_REENTRANT -fPIC"
./configure --shared
$(MAKE) -C $(BUILD_TREE) all libz.a $(TESTS)
- $(MAKE) CC=$(DEB_HOST_GNU_TYPE)-gcc -C
$(BUILD_TREE)/contrib/minizip
+ $(MAKE) CC=$(CC) -C $(BUILD_TREE)/contrib/minizip
touch $
$(STAMP_DIR)/build-64: $(STAMP_DIR)/source.make
dh_testdir
- cd $(BUILD_TREE) &&
CC="$(DEB_HOST_GNU_TYPE)-gcc -m64"
CFLAGS="-O3 -g -D_REENTRANT -fPIC" ./configure
--shared
+ cd $(BUILD_TREE) && CC="$(CC64)"
CFLAGS="-O3 -g -D_REENTRANT
-fPIC" ./configure --shared
$(MAKE) -C $(BUILD_TREE) clean
$(MAKE) -C $(BUILD_TREE) all libz.a $(TESTS)
touch $
 -73,7
+80,7 
$(STAMP_DIR)/build-nopic: $(STAMP_DIR)/source.make
dh_testdir
mkdir -p debian/nopic-tmp
- cd $(BUILD_TREE) &&
CC=$(DEB_HOST_GNU_TYPE)-gcc CFLAGS="-O3
-D_REENTRANT" ./configure
+ cd $(BUILD_TREE) && CC=$(CC)
CFLAGS="-O3 -D_REENTRANT" ./configure
$(MAKE) -C $(BUILD_TREE) clean
$(MAKE) -C $(BUILD_TREE) all libz.a $(TESTS)
$(MAKE) -C $(BUILD_TREE) install
prefix=$(CURDIR)/debian/nopic-tmp
 -84,7
+91,7 
$(STAMP_DIR)/build-64-nopic: $(STAMP_DIR)/source.make
dh_testdir
mkdir -p debian/nopic-tmp
- cd $(BUILD_TREE) &&
CC="$(DEB_HOST_GNU_TYPE)-gcc -m64"
CFLAGS="-O3 -D_REENTRANT" ./configure
--libdir=$$/lib64
+ cd $(BUILD_TREE) && CC="$(CC64)"
CFLAGS="-O3 -D_REENTRANT"
./configure --libdir=$$/lib64
$(MAKE) -C $(BUILD_TREE) clean
$(MAKE) -C $(BUILD_TREE) all libz.a $(TESTS)
$(MAKE) -C $(BUILD_TREE) install
prefix=$(CURDIR)/debian/nopic-tmp
--------------------------------------
**5.5. Create a cross compile scratchbox using sb-menu. C
- choose the powerpc-xxx-linux-gnu compiler.
- add the 'cputransp', 'doctools', 'debian' and 'perl'
devkits
- select 'qemu-ppc-0.8.1-sb2' CPU-transparancy emulation
- no rootstrap
- add 'C-library', '/etc', 'Devkits' and 'fakeroot' files to
the target
- then patch as described above in 5.1-5.3
- don't forget to set proxies if necessary for http 'export
http_proxy=
http://xxx.xxx.xxx.xxx xxx
a>'
- create a sources.list file containing an appropriate sarge
mirror for
sources. I used 'deb-src http://mirrors.ir
cam.fr/pub/debian/ sarge main'
- follow the instructions described at
http://www.s
cratchbox.org/wiki/Crocodile
Once the new sandbox has been created
[sbox-ppc860-croc: ~] >export ftp_proxy=
http://xxx.xxx.xxx.xxx xxx
a>
[sbox-ppc860-croc: ~] >export ftp_proxy=
http://xxx.xxx.xxx.xxx xxx
a>
[sbox-ppc860-croc: ~] >darcs get --set-scripts-executable
http://scratchb
ox.org/repos/crocodile
- get the crocodile files
[sbox-ppc860-croc: ~] >echo 'deb-src http://mirrors.ir
cam.fr/pub/debian/
sarge main' > /etc/apt/sources.list
[sbox-ppc860-croc: ~] >apt-get update
[sbox-ppc860-croc: ~] >mkdir crocodile-packages
[sbox-ppc860-croc: ~] >cd crocodile-packages
[sbox-ppc860-croc: ~/crocodile-packages] >apt-get source
-d acl attr
base-files base-passwd bash bc bzip2 chrpath coreutils cpio
cracklib2
db1-compat db3 db4.2 debianutils diffutils dpkg e2fsprogs
findutils
fribidi gdbm grep gzip hostname libcap libselinux libsepol
makedev mawk
modutils ncurses netbase pam perl procps readline4 sed
shadow slang
sysvinit tar tcl8.3 tcl8.4 util-linux zlib
[sbox-ppc860-croc: ~/crocodile-packages]
>dpkg-scansources .
/dev/null|gzip>Sources.gz
- get source packages to build
[sbox-ppc860-croc: ~/crocodile] >cd ../crocodile
[sbox-ppc860-croc: ~/crocodile] >echo "deb-src
file:/home/$/crocodile-packages ./" >
etc/sources.list
- setup sources.list so only the downloaded packages get
built
[sbox-ppc860-croc: ~/crocodile] >export
SBOX_UNAME_MACHINE=ppc
[sbox-ppc860-croc: ~/crocodile] >mkdir
/scratchbox/users/$/targets/`sb-conf cu`_deb_list
[sbox-ppc860-croc: ~/crocodile] >cat >
/scratchbox/users/$/targets/`sb-conf cu`_deb_list/flex
<< EOF
Source: flex
Version: 2.5.31
Binary: flex
EOF
- Setup as described in 5.1-5.2 to do the build
[sbox-ppc860-croc: ~/crocodile] >./unplanned-build.sh
--clean
- Build the crocodile packages
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
| Notes on building crosstool compilers
and crocodile packages for powerpc (PPC)
using scratchbox |

|
2007-01-02 13:13:05 |
On Thu, Dec 21, 2006 at 11:41:30AM -0500, Jim Heck wrote:
> The installation hung in the stage where it was running
the preinstall
> scripts for the packages. This may have had something
to do with
> autofs, since the installation creates an sbox user. I
confirmed that
> scratchbox installs on Debian if autofs is not used.
This probably needs to be added to release notes, FAQ, or
something
similar.
> **5.1. From Scratchbox 1.0.7 on, flex is not regarded
as a provided
> package when checking debian build deps. This is fixed
with the
> following, performed inside scratchbox.
The issue here is that flex provides libfl.a, which is
arch-specific.
Therefor some packages fail to build if flex is not
installed on target.
build dependencies of flex are included in doctools devkits,
so adding
flex to crocodiles' packages to compile is more safe
solution.
> **5.2. For powerpc, the value scratchbox returns for
'uname -m' is
> 'powerpc'. This causes problems when building
packages, since the
> scripts/makefiles generally expect 'ppc'. This is
fixed by setting the
> 'SBOX_UNAME_MACHINE' environment variable to 'ppc'
> [sbox-ppc603-croc: ~] > export
SBOX_UNAME_MACHINE=ppc
What does uname -m return on real ppc hardware? scratchbox
should match
what the real hardware returns.
> - procps required a patch to remove dependence on a
header file
> /include/asm/page.h. The use of a macro for PAGE_SIZE
resolved to a
> function and was being improperly used in a variable
declaration. I
> took code from the latest version of the package to
patch it in the
> sarge version.
I'll add this patch to crocodile, thanks.
> - zlib attempted to create the compiler name for the CC
environment
> variable using 'dpkg-architecture -qDEB_HOST_GNU_TYPE'.
This resolved
> the gcc tool name to 'powerpc-linux-gnu-gcc', but
scratchbox for some
> reason has the gcc compiler linked to
'powerpc-linux-gcc'.
These can be tuned SBOX_CROSS_GCC_PREFIX_LIST in
/targets/TARGET.config
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
| Notes on building crosstool compilers
and crocodile packages for powerpc (PPC)
using scratchbox |

|
2007-01-02 18:49:33 |
Riku Voipio wrote:
>> **5.1. From Scratchbox 1.0.7 on, flex is not
regarded as a provided
>> package when checking debian build deps. This is
fixed with the
>> following, performed inside scratchbox.
>>
>
> The issue here is that flex provides libfl.a, which is
arch-specific.
> Therefor some packages fail to build if flex is not
installed on target.
> build dependencies of flex are included in doctools
devkits, so adding
> flex to crocodiles' packages to compile is more safe
solution.
>
>
I will try this. You are saying that there is nothing
specifically
special about the flex that used to be provided in
scratchbox, so it is
essentially safer to build it as a crocodile package?
>> **5.2. For powerpc, the value scratchbox returns
for 'uname -m' is
>> 'powerpc'. This causes problems when building
packages, since the
>> scripts/makefiles generally expect 'ppc'. This is
fixed by setting the
>> 'SBOX_UNAME_MACHINE' environment variable to 'ppc'
>>
>
>
>> [sbox-ppc603-croc: ~] > export
SBOX_UNAME_MACHINE=ppc
>>
>
> What does uname -m return on real ppc hardware?
scratchbox should match
> what the real hardware returns.
>
On an actual PowerPC system, 'uname -m' returns 'ppc'. I
just confirmed
this on an PPC 8245 target system.
>
>> - zlib attempted to create the compiler name for
the CC environment
>> variable using 'dpkg-architecture
-qDEB_HOST_GNU_TYPE'. This resolved
>> the gcc tool name to 'powerpc-linux-gnu-gcc', but
scratchbox for some
>> reason has the gcc compiler linked to
'powerpc-linux-gcc'.
>>
>
> These can be tuned SBOX_CROSS_GCC_PREFIX_LIST in
/targets/TARGET.config
>
>
>
I had tried this, but it didn't seem to work.
jheck ubuntu-cross:/scratchbox/users/jheck/targets$ cat
ppc860-croc.config | grep SBOX_CROSS_GCC_PREFIX_LIST
SBOX_CROSS_GCC_PREFIX_LIST=powerpc-linux-gnu-:powerpc-860-li
nux-gnu-
jheck ubuntu-cross:/scratchbox/users/jheck/targets$
Now in the sandbox
[sbox-ppc860-croc: ~] > which powerpc-linux-gcc
/scratchbox/compilers/bin/powerpc-linux-gcc
[sbox-ppc860-croc: ~] > which powerpc-linux-gnu-gcc
[sbox-ppc860-croc: ~] >
It seems that the environment variable doesn't help
scratchbox formulate
the correct tool name. Instead, the tool name is being
found using the
set of soft links in /scratchbox/compilers/bin, which all
are formed as
'powerpc-linux-TOOL'
Are those links in /scratchbox/compilers/bin dynamically
created somehow
(and if so, what do I need to do trigger that creation), or
are they
just part of the scratchbox distribution? I could create a
whole set of
the needed ones with '-gnu' on my own, but didn't take that
step yet.
Note that all the other packages didn't have a problem
building, since
they inherited the correct tool names from make via the CC
environment
variable. The zlib package was different in that the Sarge
version of
the package tried to formulate the toolname itself in its
makefile based
on the target platform (this seems to have changed in more
recent
versions). Suggestions?
Thanks
-Jim
It seems that the
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
| Notes on building crosstool compilers
and crocodile packages for powerpc (PPC)
using scratchbox |

|
2007-01-02 23:03:47 |
On Tue, Jan 02, 2007 at 01:49:33PM -0500, Jim Heck wrote:
> Riku Voipio wrote:
> >The issue here is that flex provides libfl.a, which
is arch-specific.
> >Therefor some packages fail to build if flex is not
installed on target.
> >build dependencies of flex are included in doctools
devkits, so adding
> I will try this. You are saying that there is nothing
specifically
> special about the flex that used to be provided in
scratchbox, so it is
> essentially safer to build it as a crocodile package?
The issue is that applications that link against libfl.a
will fail
if you don't have flex installed on the target. Not all flex
using
applications use libfl, so depending on the set of packages
you
want to compile it might be a issue.
> >>[sbox-ppc603-croc: ~] > export
SBOX_UNAME_MACHINE=ppc
> >What does uname -m return on real ppc hardware?
scratchbox should match
> >what the real hardware returns.
> On an actual PowerPC system, 'uname -m' returns 'ppc'.
I just confirmed
> this on an PPC 8245 target system.
So scratchbox needs to use ppc as well. I don't have time
atm to track
where it is set up, so can you file a bug to
http://bugzi
lla.scratchbox.org/bugzilla/ ?
> It seems that the environment variable doesn't help
scratchbox formulate
> the correct tool name. Instead, the tool name is being
found using the
> set of soft links in /scratchbox/compilers/bin, which
all are formed as
> 'powerpc-linux-TOOL'
>
> Are those links in /scratchbox/compilers/bin
dynamically created somehow
> (and if so, what do I need to do trigger that
creation), or are they
> just part of the scratchbox distribution? I could
create a whole set of
> the needed ones with '-gnu' on my own, but didn't take
that step yet.
They could probably be created in sb-toolchain-extras,
currently I think
the list is hardcoded somewhere. IMNHO the whole toolchains
wrapping needs a
cleanup.
> Note that all the other packages didn't have a problem
building, since
> they inherited the correct tool names from make via the
CC environment
> variable. The zlib package was different in that the
Sarge version of
> the package tried to formulate the toolname itself in
its makefile based
> on the target platform (this seems to have changed in
more recent
> versions). Suggestions?
Not for this specific case, but in general:
1) scratchbox should look and feel like the native
enviroinment. It
should not be necessary to make scratchbox specific
workaround for
tha packages build system. Rather, scratchbox should be
fixed.
2) If packages build system is *broken*, so that it can be
identified
without scratchbox that there is bug, the build system
should be fixed.
Scratchbox is not necessarily bug-to-bug compatible.
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
| Problems with tools in debian devkit.
Can some/all tools be replaced? |

|
2007-01-05 23:12:51 |
I'm trying to build a set of packages using Crocodile beyond
the
build-essential set, to encompass enough packages to run
debootstrap
fully using only packages I have built in a reprepro
repository. Many
packages build, but a bunch are giving me grief.
Two questions, one specific and then one general.
Specific question.
One example of a package I'm having problems with is
console-data.
The first problem I had with this package was that the
'psfaddtable'
tool has changed how it takes arguments and the latest
source package in
Sarge makes use in the rules file of the tool's new argument
structure.
This was a relatively minor issue (a cat of the patch is at
the end of
this message), where a '-' that used to be required as a
file
placeholder is no longer needed (and no longer supplied in
the rules
makefile).
A more serious problem occured after I fixed this, involving
how
pbuilder-satisfydepends works to resolve and install build
dependency
packages. The problem surrounds the 'dh_consoledata' tool,
which is in
the dh-consoledata package, built as part of the
console-common source
package, and related to debhelper. Scratchbox provides a
version of
this tool. The package dependency check passes, but the
console-data
build chokes when it can't find a required file to run the
'dh_consoledata' tool as follows:
dh_consoledata -i
/scratchbox/tools/bin/sh: line 1:
/usr/share/debhelper/dh-consoledata/config.in: No such file
or directory
dh_consoledata: command returned error code
make: *** [binary-indep] Error 1
The file /usr/share/debhelper/dh-consoledata/config.in truly
does not
exist. Now I had already sucessfully built the
console-common source
package, so the dh-consoledata.deb file is sitting in my
crocodile/work/built/ directory, and could be installed.
This package
contains what I assume is an alternate working version of
the
dh_consoledata tool, including the needed files for
dh_consoledata to
work. Unfortunately, pbuilder-satisfydepends decided not to
install
that package, and use the Scratchbox provided version
instead (which is
missing the needed file).
-> Attempting to parse the build-deps :
pbuilder-satisfydepends,v 1.18
2003/04/20 03:40:36 dancer Exp $
-> Considering dbs
-> Using unversionedly scratchbox for: dbs
-> Trying dbs
-> Using scratchbox for: dbs
-> Considering debhelper (>= 4.1.6)
Using scratchbox provide: debhelper 4.2.32x
-> Trying debhelper
-> Using scratchbox for: debhelper
-> Considering dh-consoledata
-> Using unversionedly scratchbox for:
dh-consoledata
-> Trying dh-consoledata
-> Using scratchbox for: dh-consoledata
-> Considering sharutils
-> Trying sharutils
-> Considering console-tools
-> Using unversionedly scratchbox for:
console-tools
-> Trying console-tools
-> Using scratchbox for: console-tools
-> Installing sharutils
Reading Package Lists...
Building Dependency Tree...
sharutils is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not
upgraded.
-> Finished parsing the build-deps
So, in a crocodile build scenario, is it possible to have
pbuilder-satisfydepends defer to installing the package if
it is built
instead of using the Scratchbox version? Would this even
work (I can
imagine installing the second version in addition to the
Scratchbox one
could cause problems)? I'm running into several problems
more like the
first where the tool has changed and the modern Sarge
makefiles employ
the wrong syntax.
Now for the more general question. Is there a general way
people use to
build all the tools they need from sources, bypassing the
use of
many/any Scratchbox versions of the build tools. I'm not
interested in
speed, only correct execution, so I don't mind if the tools
need to run
under QEMU, so long as they run correctly. There is sort of
a chicken
and egg problem here, in that it seems you need the Debian
devkit in
order to build any packages in the first place, but would it
be possible
to then create a Scratchbox sandbox that does not include
the Debian
devkit, and instead uses the Crocodile set of packages to
provide all
the build essential tools? In other words, once
build-essential is
done, create another sandbox without the Debian devkit but
with access
to the Crocodile packages and build additional packages
here. The
documentation seems to indicate that the Debian devkit also
sets some
environment variables in addition to populating tools.
Really what I am
looking for is to have built as much from Sarge source as
possible, so
I'm depending as little as possible on specific versions of
tools from
the devkit.
I've read a bit about Scratchbox 2, and it sounds somewhat
more like
what I'm trying to do here, but I haven't found enough to
really
understand if it is ready to be fully used, and if so, what
the ins and
outs are vs the older Scratchbox.
Any help as always appreciated.
Thanks,
-Jim Heck
Example cat of patch file to fix a tool problem with
console-data:
diff -Naur console-data-2002.12.04dbs/debian/rules
console-data-2002.12.04dbs-patched/debian/rules
--- console-data-2002.12.04dbs/debian/rules 2004-11-13
11:51:10.000000000 -0500
+++ console-data-2002.12.04dbs-patched/debian/rules
2007-01-05
09:50:44.000000000 -0500
 -83,7
+83,7 
mkdir -p $/usr/share/consolefonts
# First fix the sfm tables in the lat2u fonts
for d in
$/build-tree/extras/consolefonts/lat2u-*.psf ; do
- psfaddtable $$d
$/build-tree/$/consoletrans/lat2u.sfm >
X ;
+ psfaddtable $$d
$/build-tree/$/consoletrans/lat2u.sfm -
> X ;
mv X $$d ;
done
#
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
| Problems with tools in debian devkit.
Can some/all tools be replaced? |

|
2007-01-07 11:57:58 |
On Fri, Jan 05, 2007 at 06:12:51PM -0500, Jim Heck wrote:
-snip-
> dh_consoledata -i
> /scratchbox/tools/bin/sh: line 1:
> /usr/share/debhelper/dh-consoledata/config.in: No such
file or directory
> dh_consoledata: command returned error code
> make: *** [binary-indep] Error 1
-snip-
> The file /usr/share/debhelper/dh-consoledata/config.in
truly does not
> work. Unfortunately, pbuilder-satisfydepends decided
not to install
> that package, and use the Scratchbox provided version
instead (which is
> missing the needed file).
-snip-
> So, in a crocodile build scenario, is it possible to
have
> pbuilder-satisfydepends defer to installing the package
if it is built
> instead of using the Scratchbox version? Would this
even work (I can
> imagine installing the second version in addition to
the Scratchbox one
> could cause problems)? I'm running into several
problems more like the
> first where the tool has changed and the modern Sarge
makefiles employ
> the wrong syntax.
-snip-
You are attempting to work around a issue: dh-consoledata is
broken in debian devkit. Either you can fix console-data
build rule,
or you can just remove
/scratchbox/devkits/debian/deb_list/console-common.
In general current system should match sarge, and if it
doesn't it's
a bug.
> environment variables in addition to populating tools.
Really what I am
> looking for is to have built as much from Sarge source
as possible, so
> I'm depending as little as possible on specific
versions of tools from
> the devkit.
> I've read a bit about Scratchbox 2, and it sounds
somewhat more like
> what I'm trying to do here, but I haven't found enough
to really
> understand if it is ready to be fully used, and if so,
what the ins and
> outs are vs the older Scratchbox.
This is exactly something that scratchbox2 [1] should make
possible.
Or actually better, you don't need to _avoid_ host tools in
order
to select your preferred host tools versions. You can just
install
the version you want. Currently sbox2 can build applications
(./configure ; make ; make install) , however nobody has
written
enough remapping rules to build .deb:s (should be easy) or
install
target libraries with apt-get (a more tricky problem). I
suggest you
take a closer look, sbox2 is much smaller and easier to
grasp than
1.x series. The only hard part is the remapping engine.
[1] http://rahina.org/sb2/
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
|
|
[1-6]
|
|