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

--------------------------------------
jheckubuntu-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.xxxxxx
[sbox-ct-compile: ~] >export
ftp_proxy=xxx.xxx.xxx.xxxxxx
- 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.xxxxxx'
- 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.xxxxxx
[sbox-ppc860-croc: ~] >export ftp_proxy=
http://xxx.xxx.xxx.xxxxxx
[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-userslists.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
user name
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-userslists.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
user name
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. 

jheckubuntu-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-
jheckubuntu-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-userslists.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
user name
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-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
Problems with tools in debian devkit. Can some/all tools be replaced?
user name
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-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
Problems with tools in debian devkit. Can some/all tools be replaced?
user name
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-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users
[1-6]

about | contact  Other archives ( Real Estate discussion Medical topics )