linuxdc-dev — Developer discussion list

Re: [linuxdc-dev] Confused (long)

[Renegade M. <dra...@sp...>]

>{standard input}: Assembler messages:
>{standard input}:66: Error: unknown opcode
>{standard input}:70: Error: unknown opcode

I was getting unknown opcode errors when trying to compile glibc. The fix
was to set --host=sh-linux when doing the configure. I don't know if this
applies to what you are doing, but if so, try that.
                                               -- Dan
  --------------------------------------------------------------------
            "I'm still sane on three planets and two moons."
  --------------------------------------------------------------------
      Daniel Ramaley                  3118 Cottage Grove Ave Apt 8
      dramaley at spatulacity dot cx        Des Moines, Iowa 50311
      http://www.spatulacity.cx/                    (515) 271-5233
  --------------------------------------------------------------------
       WARNING: REDISTRIBUTION OF THIS MESSAGE MAY BE IN
                VIOLATION OF APPLICABLE COPYRIGHT LAWS.
                THIS MESSAGE NOT GUARANTEED Y-TO-K COMPLIANT.

[linuxdc-dev] Confused (long)

[Adrian M. <ad...@mc...>]

The ftp site appears to be down and so I loaded the rpm for the tools package 
... but it doesn't appear to work for me.

I am sure this is because of my settings, but I am not clever enough to know 
how to set this right!

When I run...

 make 
CROSS_COMPILE=/opt/billgatliff/H-i686-pc-linux-gnu/sh4-linux/sh4-linux/bin/ 
dep zImage

I get this sort of thing...

/opt/billgatliff/H-i686-pc-linux-gnu/sh4-linux/sh4-linux/bin/gcc -D__KERNEL__ 
-I/home/Adrian/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686   -c -o 
init/main.o init/main.c
cc1: Invalid option `arch=i686'
In file included from /home/Adrian/linux/include/linux/wait.h:19,
                 from /home/Adrian/linux/include/linux/fs.h:12,
                 from /home/Adrian/linux/include/linux/capability.h:17,
                 from /home/Adrian/linux/include/linux/binfmts.h:5,
                 from /home/Adrian/linux/include/linux/sched.h:9,
                 from /home/Adrian/linux/include/linux/mm.h:4,
                 from /home/Adrian/linux/include/linux/slab.h:14,
                 from /home/Adrian/linux/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/home/Adrian/linux/include/asm/processor.h: In function `set_in_cr4':
/home/Adrian/linux/include/asm/processor.h:198: unknown register name `ax' in 
`asm'
/home/Adrian/linux/include/asm/processor.h: In function `clear_in_cr4':
/home/Adrian/linux/include/asm/processor.h:208: unknown register name `ax' in 
`asm'
In file included from /home/Adrian/linux/include/asm/semaphore.h:39,
                 from /home/Adrian/linux/include/linux/fs.h:199,
                 from /home/Adrian/linux/include/linux/capability.h:17,
                 from /home/Adrian/linux/include/linux/binfmts.h:5,
                 from /home/Adrian/linux/include/linux/sched.h:9,
                 from /home/Adrian/linux/include/linux/mm.h:4,
                 from /home/Adrian/linux/include/linux/slab.h:14,
                 from /home/Adrian/linux/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/home/Adrian/linux/include/asm/system.h: In function `__set_64bit':
/home/Adrian/linux/include/asm/system.h:147: unknown register name `dx' in 
`asm'
/home/Adrian/linux/include/asm/system.h:147: unknown register name `ax' in 
`asm'
In file included from /home/Adrian/linux/include/linux/rwsem.h:27,
                 from /home/Adrian/linux/include/asm/semaphore.h:42,
                 from /home/Adrian/linux/include/linux/fs.h:199,
                 from /home/Adrian/linux/include/linux/capability.h:17,
                 from /home/Adrian/linux/include/linux/binfmts.h:5,
                 from /home/Adrian/linux/include/linux/sched.h:9,
                 from /home/Adrian/linux/include/linux/mm.h:4,
                 from /home/Adrian/linux/include/linux/slab.h:14,
                 from /home/Adrian/linux/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/home/Adrian/linux/include/asm/rwsem.h: In function `__up_write':
/home/Adrian/linux/include/asm/rwsem.h:177: unknown register name `edx' in 
`asm'
In file included from /home/Adrian/linux/include/net/checksum.h:35,
                 from /home/Adrian/linux/include/linux/raid/md.h:34,
                 from init/main.c:24:
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:72:30: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:105:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:105:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:105:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:121:13: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:121:13: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:121:13: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:121:13: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:121:13: warning: multi-line string 
literals are deprecated
In file included from /home/Adrian/linux/include/net/checksum.h:35,
                 from /home/Adrian/linux/include/linux/raid/md.h:34,
                 from init/main.c:24:
/home/Adrian/linux/include/asm/checksum.h: At top level:
/home/Adrian/linux/include/asm/checksum.h:159: warning: `struct in6_addr' 
declared inside parameter list
/home/Adrian/linux/include/asm/checksum.h:159: warning: its scope is only 
this definition or declaration, which is probably not what you 
want./home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line 
string literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
/home/Adrian/linux/include/asm/checksum.h:161:17: warning: multi-line string 
literals are deprecated
init/main.c: In function `name_to_kdev_t':
/home/Adrian/linux/include/asm/string.h:131: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:190: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:131: inconsistent operand constraints 
in an `asm'
init/main.c: In function `root_dev_setup':
/home/Adrian/linux/include/asm/string.h:485: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:131: inconsistent operand constraints 
in an `asm'
init/main.c: In function `checksetup':
/home/Adrian/linux/include/asm/string.h:190: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:131: inconsistent operand constraints 
in an `asm'
init/main.c: In function `parse_options':
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:131: inconsistent operand constraints 
in an `asm'
/home/Adrian/linux/include/asm/string.h:154: inconsistent operand constraints 
in an `asm'
init/main.c:603: confused by earlier errors, bailing out
{standard input}: Assembler messages:
{standard input}:66: Error: unknown opcode
{standard input}:70: Error: unknown opcode
{standard input}:148: Error: unknown opcode
{standard input}:149: Error: unknown opcode
{standard input}:150: Error: unknown opcode
{standard input}:172: Error: unknown opcode
{standard input}:173: Error: unknown opcode
{standard input}:174: Error: unknown opcode
{standard input}:185: Error: unknown opcode
{standard input}:186: Error: unknown opcode
{standard input}:187: Error: unknown opcode
{standard input}:188: Error: unknown opcode
{standard input}:189: Error: unknown opcode
{standard input}:190: Error: unknown opcode
{standard input}:191: Error: unknown opcode
{standard input}:192: Error: unknown opcode
{standard input}:193: Error: unknown opcode
{standard input}:277: Error: unknown opcode
{standard input}:277: Error: unknown opcode
{standard input}:277: Error: unknown opcode
{standard input}:277: Error: unknown opcode
{standard input}:1592: Error: unknown opcode
{standard input}:1697: Error: unknown opcode
{standard input}:1743: Error: unknown opcode
{standard input}:1772: Error: unknown opcode
{standard input}:1772: Error: unknown opcode
{standard input}:1773: Error: unknown opcode
{standard input}:1775: Error: unknown opcode
{standard input}:1776: Error: unknown opcode
{standard input}:1777: Error: unknown opcode
{standard input}:1778: Error: invalid operands for opcode
make: *** [init/main.o] Error 1


Eeeek! What's wrong???

Re: [linuxdc-dev] Newbie now having trouble with glibc

[M. R. B. <mr...@0x...>]

* Renegade Muskrat <dra...@sp...> on Sat, Sep 08, 2001:

> 
> This sort of makes sense. I originally configured glibc with
> --prefix=${PREFIX}/${TARGET} (where PREFIX is /usr/local/sh-linux and
> TARGET is sh-linux). So then should i still set install_root to
> /usr/local/sh-linux/sh-linux (which is the same as the configure prefix i
> originally used) and prefix to an empty string?
> 

Check out the "Building LinuxSH from Scratch" document on
linuxsh.sourceforge.net and adapt the glibc section to your needs.  You
always configure --prefix to ${PREFIX}, and when installing, install_root
is ${PREFIX}/${TARGET} - not the other way around ;).

M. R.

Re: [linuxdc-dev] Newbie now having trouble with glibc

[Renegade M. <dra...@sp...>]

>> touch iconv/iconv_prog login/pt_chown
>> make install_root=${PREFIX} prefix="" install
>> 
>> Various instruction sets give slightly different options for the --prefix
>> from the original glibc configure and for the install_root during the
>> install. But basically it looks to me like they set the configure prefix to
>> one thing, but then during the install place the files somewhere else. What
>> is the point to doing this? Why not just set the --prefix in the configure
>> to the final place to begin with?
>
>In the binutils/gcc/glibc echelon, in your example (sh-linux) everything is
>kept under /prefix/sh-linux/.  By default, ld looks for libraries and cpp
>looks for headers in /prefix/sh-linux/sh-linux, as you can have multiple
>sets of tools installed in the same prefix.  In your above line, your
>install_root should actually be ${PREFIX}/sh-linux or cpp and ld won't be
>able to find the includes and libs.  Also, don't forget to edit
>${PREFIX}/sh-linux/lib/libc.so (once glibc is installed) and removed the
>"/lib/" prefixes from the two filenames contained therein.

This sort of makes sense. I originally configured glibc with
--prefix=${PREFIX}/${TARGET} (where PREFIX is /usr/local/sh-linux and
TARGET is sh-linux). So then should i still set install_root to
/usr/local/sh-linux/sh-linux (which is the same as the configure prefix i
originally used) and prefix to an empty string?


Incidentally, it doesn't really matter yet since glibc still managed to hit
a compile error last night. This morning i'm trying again with slightly
different options (i changed the configure prefix from ${PREFIX}/${TARGET}
to ${PREFIX} and will see if that matters).

Re: [linuxdc-dev] Newbie now having trouble with glibc

[M. R. B. <mr...@0x...>]

* Renegade Muskrat <dra...@sp...> on Sat, Sep 08, 2001:

> 
> Thank you much for the quick and accurate response. Glibc is compiling as i
> type this. I have another quick question, though. The documentation i've
> been reading on how to compile glibc suggests doing the following to
> actually install glibc once it is built:
> 
> touch iconv/iconv_prog login/pt_chown
> make install_root=${PREFIX} prefix="" install
> 
> Various instruction sets give slightly different options for the --prefix
> from the original glibc configure and for the install_root during the
> install. But basically it looks to me like they set the configure prefix to
> one thing, but then during the install place the files somewhere else. What
> is the point to doing this? Why not just set the --prefix in the configure
> to the final place to begin with?
>                                                -- Dan

In the binutils/gcc/glibc echelon, in your example (sh-linux) everything is
kept under /prefix/sh-linux/.  By default, ld looks for libraries and cpp
looks for headers in /prefix/sh-linux/sh-linux, as you can have multiple
sets of tools installed in the same prefix.  In your above line, your
install_root should actually be ${PREFIX}/sh-linux or cpp and ld won't be
able to find the includes and libs.  Also, don't forget to edit
${PREFIX}/sh-linux/lib/libc.so (once glibc is installed) and removed the
"/lib/" prefixes from the two filenames contained therein.

Note this is how you can *technically* install your cross-tools in /usr or
/usr/local, as all specific includes and libs will go under the
target-named subdir and gcc-specific stuff (libgcc.a, other crud) under
/prefix/lib/gcc-lib/sh-linux/<gcc version>/.  So *technically* you can
install 10 sets of cross-tools to varying targets and they can peacefully
coexist with your host gcc ... but you're always advised to choose an out
of the way prefix :P.

HTH,

M. R.

Re: [linuxdc-dev] Newbie now having trouble with glibc

[Renegade M. <dra...@sp...>]

>> CC="${TARGET}-gcc -ml -m4" ../glibc-2.2.2/configure \
>>      --host=${HOST} --build=${HOST} --target=${TARGET} \
>>      --prefix=${PREFIX}/${TARGET} --enable-add-ons \
>>      --with-headers=${PREFIX}/linux/include \
>>      --with-binutils=${PREFIX}/bin \
>>      2>&1 | tee -a configure.out
>> make -w all \
>>      2>&1 | tee -a make.out
>> 
>> 
>This would very likely be breaking because TARGET=HOST in glibc.. so you're
>essentially building an i686-pc-linux-gnu glibc with your sh-linux version of
>gcc -- no good can come of that.
>
>Change your --host=${HOST} to --host=${TARGET} and try again..

Thank you much for the quick and accurate response. Glibc is compiling as i
type this. I have another quick question, though. The documentation i've
been reading on how to compile glibc suggests doing the following to
actually install glibc once it is built:

touch iconv/iconv_prog login/pt_chown
make install_root=${PREFIX} prefix="" install

Various instruction sets give slightly different options for the --prefix
from the original glibc configure and for the install_root during the
install. But basically it looks to me like they set the configure prefix to
one thing, but then during the install place the files somewhere else. What
is the point to doing this? Why not just set the --prefix in the configure
to the final place to begin with?
                                               -- Dan
  --------------------------------------------------------------------
            "I'm still sane on three planets and two moons."
  --------------------------------------------------------------------
      Daniel Ramaley                  3118 Cottage Grove Ave Apt 8
      dramaley at spatulacity dot cx        Des Moines, Iowa 50311
      http://www.spatulacity.cx/                    (515) 271-5233
  --------------------------------------------------------------------
       WARNING: REDISTRIBUTION OF THIS MESSAGE MAY BE IN
                VIOLATION OF APPLICABLE COPYRIGHT LAWS.
                THIS MESSAGE NOT GUARANTEED Y-TO-K COMPLIANT.

Re: [linuxdc-dev] Newbie now having trouble with glibc

[Paul M. <pm...@MV...>]

On Sat, Sep 08, 2001 at 12:22:15AM -0500, Renegade Muskrat wrote:
> It looks to me like there are a lot of references to i386 stuff when i
> probably want references to sh stuff. How do i correct this? If it would
> help, below is the list of commands i've executed to get to this point; t=
he
> interesting stuff involving glibc is naturally at the bottom. Any help or
> suggestions would be greatly appreciated. Thanks!
>=20
>=20
> HOST=3Di686-pc-linux-gnu
> TARGET=3Dsh-linux
> ARCH=3Dsh
> BASE=3D/home/build
> PREFIX=3D/usr/local/${TARGET}
> PATH=3D${PREFIX}/bin:${PATH}
>=20
[snip]
>=20
> # glibc
>=20
> cd ${BASE}
> tar -xvIf glibc-2.2.2.tar.bz2
> bunzip2 -c glibc-linuxthreads-2.2.2.tar.bz2 | \
>      (cd glibc-2.2.2 ; tar -xvf -)
> gunzip -c sh-glibc-2.2.2-pthread+arch+ver.diff.gz | patch -p0
> mkdir build-glibc
> cd build-glibc
> echo "CFLAGS :=3D -ml -m4 -O \$(CFLAGS)
> ASFLAGS-.o :=3D -ml
> LDFLAGS-relocatable :=3D -ml
> crts-predefined=3Dyes
> build-programs=3Dno
> CC=3D${TARGET}-gcc -ml -m4
> RANLIB=3D${TARGET}-ranlib
> AS=3D${TARGET}-gcc -ml
> LD=3D${TARGET}-ld -ml
> AR=3D${TARGET}-ar
> BUILD_CC=3Dgcc" > configparms
> CC=3D"${TARGET}-gcc -ml -m4" ../glibc-2.2.2/configure \
>      --host=3D${HOST} --build=3D${HOST} --target=3D${TARGET} \
>      --prefix=3D${PREFIX}/${TARGET} --enable-add-ons \
>      --with-headers=3D${PREFIX}/linux/include \
>      --with-binutils=3D${PREFIX}/bin \
>      2>&1 | tee -a configure.out
> make -w all \
>      2>&1 | tee -a make.out
>=20
>=20
This would very likely be breaking because TARGET=3DHOST in glibc.. so you'=
re
essentially building an i686-pc-linux-gnu glibc with your sh-linux version =
of
gcc -- no good can come of that.

Change your --host=3D${HOST} to --host=3D${TARGET} and try again..

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

[linuxdc-dev] Newbie now having trouble with glibc

[Renegade M. <dra...@sp...>]

With assistance from this group i have managed to compile binutils and gcc,
but am now having trouble with glibc (i must not yet grok some basic
concept involved with setting up cross compilers to be having so many
difficulties). Compilation runs for a bit and then i get messages like this:

../sysdeps/unix/sysv/linux/i386/sysdep.S: Assembler messages:
../sysdeps/unix/sysv/linux/i386/sysdep.S:28: Error: Unknown pseudo-op:  `.bss'
../sysdeps/unix/sysv/linux/i386/sysdep.S:50: Error: Alignment too large: 15
assumed
../sysdeps/unix/sysv/linux/i386/sysdep.S:51: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:47: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:49: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:51: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:52: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:74: Error: unknown opcode
../sysdeps/unix/i386/sysdep.S:75: Error: unknown opcode


Here's the (rather lengthy) command that make was trying to execute:


sh-linux-gcc -ml -m4 ../sysdeps/unix/sysv/linux/i386/sysdep.S -c
-I../include -I. -I/home/build/build-glibc/csu -I.. -I../libio
-I/home/build/build-glibc -I../sysdeps/i386/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/i386
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/i386/i686 -I../linuxthreads/sysdeps/i386
-I../sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386
-I../sysdeps/unix/sysv -I../sysdeps/unix/i386/i686
-I../sysdeps/unix/i386/i586 -I../sysdeps/unix/i386 -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686
-I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic
-nostdinc -isystem /usr/local/sh-linux/lib/gcc-lib/sh-linux/3.0/include
-isystem /usr/local/sh-linux/linux/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h     -DHAVE_INITFINI -DASSEMBLER
-I/home/build/build-glibc/csu/. -DGAS_SYNTAX -ml -o
/home/build/build-glibc/csu/sysdep.o


It looks to me like there are a lot of references to i386 stuff when i
probably want references to sh stuff. How do i correct this? If it would
help, below is the list of commands i've executed to get to this point; the
interesting stuff involving glibc is naturally at the bottom. Any help or
suggestions would be greatly appreciated. Thanks!


HOST=i686-pc-linux-gnu
TARGET=sh-linux
ARCH=sh
BASE=/home/build
PREFIX=/usr/local/${TARGET}
PATH=${PREFIX}/bin:${PATH}

# files have been downloaded to $BASE, with the kernel in $BASE/kernel.

# binutils

cd ${BASE}
tar -xvIf binutils-010513.tar.bz2
gunzip -c sh-binutils-010513-rela+arch+opc.diff.gz | patch -p0
mkdir build-binutils
cd build-binutils
../binutils-010513/configure --target=${TARGET} --prefix=${PREFIX} -v \
     2>&1 | tee -a configure.out
make -w all install \
     2>&1 | tee -a make.out

# gcc

cd ${BASE}
tar -xvIf gcc-core-20010514.tar.bz2
tar -xvIfgcc-g++-20010514.tar.bz2
gunzip -c sh-gcc-20010514-arch+pic+wind+misc.diff.gz | patch -p0
mkdir build-gcc0
cd build-gcc0
../gcc-20010514/configure --host=${HOST} --target=${TARGET} \
     --prefix=${PREFIX} --without-headers --with-newlib \
     --disable-shared -v \
     2>&1 | tee -a configure.out
make -w all-gcc install-gcc \
     2>&1 | tee -a make.out

# kernel, round 1

cd ${BASE}
mv kernel ${PREFIX}/linux
cd ${PREFIX}/linux
make ARCH=${ARCH} menuconfig
make ARCH=${ARCH} dep
cd ${PREFIX}/include
ln -s ${PREFIX}/linux/include/asm-${ARCH} asm
ln -s ${PREFIX}/linux/include/linux linux

# glibc

cd ${BASE}
tar -xvIf glibc-2.2.2.tar.bz2
bunzip2 -c glibc-linuxthreads-2.2.2.tar.bz2 | \
     (cd glibc-2.2.2 ; tar -xvf -)
gunzip -c sh-glibc-2.2.2-pthread+arch+ver.diff.gz | patch -p0
mkdir build-glibc
cd build-glibc
echo "CFLAGS := -ml -m4 -O \$(CFLAGS)
ASFLAGS-.o := -ml
LDFLAGS-relocatable := -ml
crts-predefined=yes
build-programs=no
CC=${TARGET}-gcc -ml -m4
RANLIB=${TARGET}-ranlib
AS=${TARGET}-gcc -ml
LD=${TARGET}-ld -ml
AR=${TARGET}-ar
BUILD_CC=gcc" > configparms
CC="${TARGET}-gcc -ml -m4" ../glibc-2.2.2/configure \
     --host=${HOST} --build=${HOST} --target=${TARGET} \
     --prefix=${PREFIX}/${TARGET} --enable-add-ons \
     --with-headers=${PREFIX}/linux/include \
     --with-binutils=${PREFIX}/bin \
     2>&1 | tee -a configure.out
make -w all \
     2>&1 | tee -a make.out

Re: [linuxdc-dev] Newbie having trouble with gcc

[Renegade M. <dra...@sp...>]

>> ../gcc-20010514/configure --host=${HOST} --target=${TARGET} \
>>      --without-headers --with-newlib -v \
>>      2>&1 | tee -a configure.out
>
>You forgot --prefix=${PREFIX} here.

Thank you. Such a silly mistake on my part. I added the --prefix and it
died complaining about crti.o. But i remembered from other posts to this
lists that adding --disable-shared to the configure line fixes the crti.o
problem, so i tried again and it worked.
                                               -- Dan
  --------------------------------------------------------------------
            "I'm still sane on three planets and two moons."
  --------------------------------------------------------------------
      Daniel Ramaley                  3118 Cottage Grove Ave Apt 8
      dramaley at spatulacity dot cx        Des Moines, Iowa 50311
      http://www.spatulacity.cx/                    (515) 271-5233
  --------------------------------------------------------------------
       WARNING: REDISTRIBUTION OF THIS MESSAGE MAY BE IN
                VIOLATION OF APPLICABLE COPYRIGHT LAWS.
                THIS MESSAGE NOT GUARANTEED Y-TO-K COMPLIANT.

Re: [linuxdc-dev] Newbie having trouble with gcc

[M. R. B. <mr...@0x...>]

* Renegade Muskrat <dra...@sp...> on Mon, Sep 03, 2001:

> TARGET=sh-linux
> BASE=/home/build
> PREFIX=/usr/local/${TARGET}
> PATH=${PREFIX}/bin:${PATH}
> 

[...]

> 
> # gcc
> 
> cd ${BASE}
> tar -xvIf gcc-core-20010514.tar.bz2
> tar -xvIfgcc-g++-20010514.tar.bz2
> gunzip -c sh-gcc-20010514-arch+pic+wind+misc.diff.gz | patch -p0
> mkdir build-gcc
> cd build-gcc
> ../gcc-20010514/configure --host=${HOST} --target=${TARGET} \
>      --without-headers --with-newlib -v \
>      2>&1 | tee -a configure.out

You forgot --prefix=${PREFIX} here.

M. R.

Re: [linuxdc-dev] Newbie having trouble with gcc

[Renegade M. <dra...@sp...>]

>> I am using /usr/local/sh-linux as my target directory. I already had
>> /usr/local/sh-linux/bin as the first entry in the PATH. Should i have a
>> different directory in the PATH as well?
>
>Hmm, no that should be correct.  Could you post your configure command
>lines for binutils and gcc?

Here is the complete list of commands that i have run so far. If it would
help to see the output of the configure and make commands, i can post them
to a web page upon request. Anything i'm doing wrong here?



HOST=i686-pc-linux-gnu
TARGET=sh-linux
BASE=/home/build
PREFIX=/usr/local/${TARGET}
PATH=${PREFIX}/bin:${PATH}

# binutils

cd ${BASE}
tar -xvIf binutils-010513.tar.bz2
gunzip -c sh-binutils-010513-rela+arch+opc.diff.gz | patch -p0
mkdir build-binutils
cd build-binutils
../binutils-010513/configure --target=${TARGET} --prefix=${PREFIX} -v \
     2>&1 | tee -a configure.out
make -w all install \
     2>&1 | tee -a make.out

# gcc

cd ${BASE}
tar -xvIf gcc-core-20010514.tar.bz2
tar -xvIfgcc-g++-20010514.tar.bz2
gunzip -c sh-gcc-20010514-arch+pic+wind+misc.diff.gz | patch -p0
mkdir build-gcc
cd build-gcc
../gcc-20010514/configure --host=${HOST} --target=${TARGET} \
     --without-headers --with-newlib -v \
     2>&1 | tee -a configure.out
make -w all-gcc install-gcc \
     2>&1 | tee -a make.out

Re: [linuxdc-dev] Newbie having trouble with gcc

[M. R. B. <mr...@0x...>]

* Renegade Muskrat <dra...@sp...> on Mon, Sep 03, 2001:

> 
> I am using /usr/local/sh-linux as my target directory. I already had
> /usr/local/sh-linux/bin as the first entry in the PATH. Should i have a
> different directory in the PATH as well?
> 

Hmm, no that should be correct.  Could you post your configure command
lines for binutils and gcc?

M. R.

Re: [linuxdc-dev] Newbie having trouble with gcc

[Renegade M. <dra...@sp...>]

Thank you for your response.

I am using /usr/local/sh-linux as my target directory. I already had
/usr/local/sh-linux/bin as the first entry in the PATH. Should i have a
different directory in the PATH as well?

>Make sure that the cross-compiled binutils is on your PATH after you build
>them.  The error above is from gcc's cross-compiler system not being able
>to find the cross binutils and falling back on your system (presumably
>i386-based) assembler.
>
>M. R.

Re: [linuxdc-dev] Newbie having trouble with gcc

[M. R. B. <mr...@0x...>]

* Renegade Muskrat <dra...@sp...> on Sun, Sep 02, 2001:

> Hello. I've been trying to build a cross compiler but so far have had no
> luck. Following the instructions in the Tools section, binutils installs
> just fine. But when building gcc, there are problems. Compilation goes for
> awhile and then i get this:
> 
> as: unrecognized option `-little'
> make[2]: *** [libgcc/./_ashiftrt.o] Error 1
> make[2]: Leaving directory `/home/build/build-gcc/gcc'
> make[1]: *** [stmp-multilib] Error 2
> make[1]: Leaving directory `/home/build/build-gcc/gcc'
> make: *** [all-gcc] Error 2
> make: Leaving directory `/home/build/build-gcc'
> 

Make sure that the cross-compiled binutils is on your PATH after you build
them.  The error above is from gcc's cross-compiler system not being able
to find the cross binutils and falling back on your system (presumably
i386-based) assembler.

M. R.

[linuxdc-dev] Newbie having trouble with gcc

[Renegade M. <dra...@sp...>]

Hello. I've been trying to build a cross compiler but so far have had no
luck. Following the instructions in the Tools section, binutils installs
just fine. But when building gcc, there are problems. Compilation goes for
awhile and then i get this:

as: unrecognized option `-little'
make[2]: *** [libgcc/./_ashiftrt.o] Error 1
make[2]: Leaving directory `/home/build/build-gcc/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/build/build-gcc/gcc'
make: *** [all-gcc] Error 2
make: Leaving directory `/home/build/build-gcc'

I've never tried building a cross compiler before. I'm running a Red Hat
6.2 system. I tried upgrading some of the compilation tools, but i still
run into the problem. Here's the versions of some of the tools that i'm using:

make - 3.79
gcc  - 2.95.3
ar   - 2.11.2

Any ideas? Any help would be greatly appreciated. I would really like to be
able to build software for my Dreamcast so that i can start developing for
it and learn how to port packages to it.
                                               -- Dan
  --------------------------------------------------------------------
            "I'm still sane on three planets and two moons."
  --------------------------------------------------------------------
      Daniel Ramaley                  3118 Cottage Grove Ave Apt 8
      dramaley at spatulacity dot cx        Des Moines, Iowa 50311
      http://www.spatulacity.cx/                    (515) 271-5233
  --------------------------------------------------------------------
       WARNING: REDISTRIBUTION OF THIS MESSAGE MAY BE IN
                VIOLATION OF APPLICABLE COPYRIGHT LAWS.
                THIS MESSAGE NOT GUARANTEED Y-TO-K COMPLIANT.

[linuxdc-dev] =?ISO-2022-JP?B?GyRCPi5AdEZiM1UbKEIgGyRCO1k7fUlUO1k7fTZbNV4bKEI=?= =?ISO-2022-JP?B?GyRCJSIlcyUxITwlSBsoQg==?=

[<sor...@ec...>]

小泉内閣　支持・不支持　緊急アンケート

お忙しいところ、ご迷惑をおかけしますが、 
下のURLをクリックして、アンケートにご協力お願いいたします。 

http://211.9.37.210/koizumi/koizumi_an.asp?id=206398

[linuxdc-dev] missing file

[Paul H. <pau...@cr...>]

Hi

I have successfully built the kernel following the instructions in the =
Kernel How To, the problem I have is when it comes to setting the kernel =
boot parameters, there is a default options file, but this is a broken =
link does anyone have a copy of this file, or can anyone tell me how to =
create this file

Other than that it's all worked a treat

Paul Hirst

Re: [linuxdc-dev] VMS flash handling

[Paul M. <pm...@mv...>]

On Wed, Jul 04, 2001 at 05:49:44PM +0200, Frederic SOULIER wrote:
>   In France, this costs about $30. So 1MB is enough for a full linux
> kernel (compressed or not), I wondered if booting my dreamcast from
> MAPLE bus was possible ? It would be very fine for me, since these kinds
> of "Visual Memory" are usually shipped with serial / parallel port or
> USB cable + interface for PC.
>=20
This all depends on how you intend to access the thing and how exactly you
want to boot. I've seen a number of these VMU's that have interface cables,
and the only software I've seen for them interact with the device while
keeping the vmufs intact so you can hex edit a rom dump and sync it back up.

The only problem with this is that you need a firmware that is intelligent
enough to communicate with maple, and you need to be able to pull down the
kernel image into memory in blocks, as you don't have any direct access to =
the
device itself. All you can do is read/write blocks from the VMU over maple,
where you're required to know the port and unit id.

So, in theory, you could hack something like RedBoot to be able to handle
maple, and simply read in the kernel image one block at a time.. then map
it into memory, and set the start address to the beginning of the mapped
region, and boot from there.

You wouldn't really get much benefit from this in my opinion, but oh well.

>   So after cross-compiling, you should have only to upload the code to
> the flash and then boot your DC from your joypad ! :)  (kidding, but
> this could be more flexible than a home made serial cable).
>=20
>   Well, does anyone know if all this is possible ?
>=20
Writing is still a touchy subject. I've been working on an MTD driver for
the VMU, though it interacts with the device over maple directly, and
the block reads/writes are handled by an underlying flash mapping driver.

The upside to this is that you can fully use it like any other embedded
storage device, but you have to do it over maple.. which requires having
the DC already booted and writing it from there.

I suppose you could extend my flash mapping driver to communicate over
serial in addition to maple.. but that'd be pretty useless.

The only other option you have, is to try and dump to flash raw data that
doesn't comply with the vmufs or any other filesystem, and then try and
map that into memory.. that'd be the simplest way to go about it, but it
renders the VMU pretty much useless for anything else until you can restore
the vmufs.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxdc-dev] VMS flash handling

[Frederic S. <fre...@sx...>]

> So, in theory, you could hack something like RedBoot to be able to handle
> maple, and simply read in the kernel image one block at a time.. then map
> it into memory, and set the start address to the beginning of the mapped
> region, and boot from there.

Oh yes ... I said boot from VMU but code relocation (not mapping) into
memory before booting should be better.
 
> You wouldn't really get much benefit from this in my opinion, but oh well.

Flexibility.
 
> Writing is still a touchy subject. I've been working on an MTD driver for
> the VMU, though it interacts with the device over maple directly, and
> the block reads/writes are handled by an underlying flash mapping driver.

That is very interesting. But IMHO VMU flash capacity is very low.
Writing some code which is near a flash file system is a big job. I
think taht work around JFFS is a good example.
 
> The upside to this is that you can fully use it like any other embedded
> storage device, but you have to do it over maple.. which requires having
> the DC already booted and writing it from there.

This is definitely very interesting.
For me, needs are more about core kernel development and an easy way to
boot a custom one from flash (faster than read an image from serial
link).
 
> The only other option you have, is to try and dump to flash raw data that
> doesn't comply with the vmufs or any other filesystem, and then try and
> map that into memory.. that'd be the simplest way to go about it, but it
> renders the VMU pretty much useless for anything else until you can restore
> the vmufs.

It is absolutely that I want :)

Thanks for all these interesting information.

BRs,

Fred.

Re: [linuxdc-dev] Re: Compiling issues with gcc

[Nick B. <ni...@ia...>]

On Wed, Jul 04, 2001 at 02:53:34PM -0500, John Wiggins wrote:
> While going through the IRC chats from June, I came across someone else 
> having this issue.  The solution is as follows:
> 
> Very brief instructions taken from Tools:
> 
> 1) untar gcc
> 2) patch
> 3) mkdir build-gcc
> 4) at the: ../gcc-2.../configure part, append --disable-shared after 
> --with-newlib
> I got it to compile with this fix.

Thanks, I did  succeed now....., I've a sh4 gcc and cpp now.


Greetings,

Nick Brok
--  
ICQ:48844045          Email: ni...@ia...

[linuxdc-dev] Re: Compiling issues with gcc

[John W. <lin...@ho...>]

While going through the IRC chats from June, I came across someone else 
having this issue.  The solution is as follows:

Very brief instructions taken from Tools:

1) untar gcc
2) patch
3) mkdir build-gcc
4) at the: ../gcc-2.../configure part, append --disable-shared after 
--with-newlib
I got it to compile with this fix.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [linuxdc-dev] Compiling gcc...

[Nick B. <ni...@ia...>]

On Wed, Jul 04, 2001 at 01:09:07PM -0500, John Wiggins wrote:
> Surprisingly, I finally got around to making a serial cable (broadband still 
> on backorder) anyway, following the steps verbatum from the Tools section, 
> the binutils compiled and installed perfectly, however when I went to 
> compile the gcc... well, here's what I got back:
> 
> /usr/local/sh4-linux/sh4-linux/bin/ld: cannot open crti.o: No such file or 
> directory
> collect2: ld returned 1 exit status
> make[2]: *** [libgcc_s.so] Error 1
> make[2]: Leaving directory `/home/jwiggins/linuxdc/build-gcc/gcc'
> make[1]: *** [libgcc.a] Error 2
> make[1]: Leaving directory `/home/jwiggins/linuxdc/build-gcc/gcc'
> make: *** [all-gcc] Error
> 
> I can give the entire message if need be.  As I am relativly "new" to the 
> cross-compiling age; I'm sure this will turn out to just be stupidity on my 
> part but I would love to get past this barrier.

This is exactly the same problem I got also.... I tried many cross GCC's for
several CPU's but never succeeded.
So I'm not the only one out their with this problem.....

Greetings,

Nick Brok
--  
ICQ:48844045          Email: ni...@ia...

[linuxdc-dev] Compiling gcc...

[John W. <lin...@ho...>]

Surprisingly, I finally got around to making a serial cable (broadband still 
on backorder) anyway, following the steps verbatum from the Tools section, 
the binutils compiled and installed perfectly, however when I went to 
compile the gcc... well, here's what I got back:

/usr/local/sh4-linux/sh4-linux/bin/ld: cannot open crti.o: No such file or 
directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: Leaving directory `/home/jwiggins/linuxdc/build-gcc/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory `/home/jwiggins/linuxdc/build-gcc/gcc'
make: *** [all-gcc] Error

I can give the entire message if need be.  As I am relativly "new" to the 
cross-compiling age; I'm sure this will turn out to just be stupidity on my 
part but I would love to get past this barrier.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

[linuxdc-dev] VMS flash handling

[Frederic S. <fre...@sx...>]

 Hello there !

  Some companies sell some competitive "Visual Memory" (with 4 or 8 time
more capacity -> up to 1MB).
  In France, this costs about $30. So 1MB is enough for a full linux
kernel (compressed or not), I wondered if booting my dreamcast from
MAPLE bus was possible ? It would be very fine for me, since these kinds
of "Visual Memory" are usually shipped with serial / parallel port or
USB cable + interface for PC.

  So after cross-compiling, you should have only to upload the code to
the flash and then boot your DC from your joypad ! :)  (kidding, but
this could be more flexible than a home made serial cable).

  Well, does anyone know if all this is possible ?

Thanks,

Fred.

Re: [linuxdc-dev] Re: [linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[M. R. B. <mr...@0x...>]

* Peter De Schrijver <p2...@mi...> on Thu, May 24, 2001:

> 
> Last weekend I tried the cvs snapshot of the DC Linux kernel on a dreamcast
> with BBA. I downloaded the kernel via the serial port. I had to make some 
> small changes to the pci_gaps code to get the BBA to work.
> 

Yeah, I had those problems before, but Yaegashi's BBA code doesn't exhibit
that bug (uploading over serial won't init the BBA).  I still need to merge
what I did last nite back into LinuxDC, so for the next couple of hours
LinuxSH contains the most recent kernel :).  I've tested the BBA with both
BBA upload and serial upload, and it appears to work fine.

> > - Finish rewriting Maple subsystem
> > - Finish drivers for the vmu MTD flash and LCD fb
> > - Finish AICA RTC stuff
> > - GD-ROM support
> > - MTD driver for DC's internal flash
> 
> Any pointers on this ? I have done some work on MTD drivers.
> 

Paul Mundt (Lethal) and myself (mrbrown) hang out in #linuxdc on
irc.openprojects.net.  This is where we do the majority of discussion on
the Maple stuff.  Once I do the (LinuxDC) merge, we'll probably start
committing things to LinuxDC CVS, and you're welcome to stop by to get a
bead on where things are going.

The internal flash interface requires more info than what I have currently,
and Marcus Comstedt seems to know the most about its specifics.

> 
> I was planning on looking into this RSN. I have experience with ARM programming
> on both linux and eCos. I was thinking of running eCos on the AICA :)
> 

Wow, I've actually been trying to stay away from the ARM as much as
possible :).  As soon as you have a patch (even your pci_gaps fix from
above would be fine), send me it with your SF info and I'll add you to the
list of developers :).

M. R.