You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(13) |
Feb
(12) |
Mar
(14) |
Apr
(3) |
May
(25) |
Jun
|
Jul
(9) |
Aug
|
Sep
(47) |
Oct
(24) |
Nov
(23) |
Dec
(58) |
2002 |
Jan
(87) |
Feb
(54) |
Mar
(38) |
Apr
(6) |
May
(11) |
Jun
(7) |
Jul
(13) |
Aug
(39) |
Sep
(58) |
Oct
(20) |
Nov
(63) |
Dec
(46) |
2003 |
Jan
|
Feb
|
Mar
(8) |
Apr
(52) |
May
(21) |
Jun
(2) |
Jul
(10) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2004 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(46) |
Jul
(15) |
Aug
(1) |
Sep
(12) |
Oct
(3) |
Nov
(4) |
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
2007 |
Jan
(8) |
Feb
(16) |
Mar
(17) |
Apr
(16) |
May
(21) |
Jun
(17) |
Jul
(40) |
Aug
(62) |
Sep
(30) |
Oct
(14) |
Nov
(7) |
Dec
(9) |
2008 |
Jan
(4) |
Feb
(7) |
Mar
(36) |
Apr
(22) |
May
(21) |
Jun
(9) |
Jul
(35) |
Aug
(17) |
Sep
(21) |
Oct
(24) |
Nov
(61) |
Dec
(85) |
2009 |
Jan
(51) |
Feb
(36) |
Mar
(60) |
Apr
(77) |
May
(154) |
Jun
(118) |
Jul
(86) |
Aug
(30) |
Sep
(20) |
Oct
(31) |
Nov
(10) |
Dec
(25) |
2010 |
Jan
(15) |
Feb
(17) |
Mar
(38) |
Apr
(59) |
May
(84) |
Jun
(63) |
Jul
(39) |
Aug
(43) |
Sep
(12) |
Oct
(6) |
Nov
(2) |
Dec
(2) |
2011 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(4) |
Dec
(1) |
2012 |
Jan
(3) |
Feb
(1) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(7) |
Oct
(8) |
Nov
(1) |
Dec
(9) |
2014 |
Jan
(8) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
(5) |
Aug
(5) |
Sep
(3) |
Oct
(11) |
Nov
(5) |
Dec
(6) |
2015 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2016 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(3) |
2017 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Renegade M. <dra...@sp...> - 2001-09-11 00:18:15
|
>{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. |
From: Adrian M. <ad...@mc...> - 2001-09-10 22:59:08
|
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??? |
From: M. R. B. <mr...@0x...> - 2001-09-08 14:54:31
|
* 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. |
From: Renegade M. <dra...@sp...> - 2001-09-08 14:42:43
|
>> 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). |
From: M. R. B. <mr...@0x...> - 2001-09-08 07:07:41
|
* 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. |
From: Renegade M. <dra...@sp...> - 2001-09-08 06:02:37
|
>> 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. |
From: Paul M. <pm...@MV...> - 2001-09-08 05:38:11
|
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. |
From: Renegade M. <dra...@sp...> - 2001-09-08 05:22:24
|
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 |
From: Renegade M. <dra...@sp...> - 2001-09-04 12:12:39
|
>> ../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. |
From: M. R. B. <mr...@0x...> - 2001-09-04 02:16:58
|
* 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. |
From: Renegade M. <dra...@sp...> - 2001-09-04 01:34:23
|
>> 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 |
From: M. R. B. <mr...@0x...> - 2001-09-03 15:47:09
|
* 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. |
From: Renegade M. <dra...@sp...> - 2001-09-03 15:36:27
|
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. |
From: M. R. B. <mr...@0x...> - 2001-09-03 14:53:40
|
* 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. |
From: Renegade M. <dra...@sp...> - 2001-09-03 03:34:27
|
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. |
From: <sor...@ec...> - 2001-07-27 16:09:13
|
小泉内閣 支持・不支持 緊急アンケート お忙しいところ、ご迷惑をおかけしますが、 下のURLをクリックして、アンケートにご協力お願いいたします。 http://211.9.37.210/koizumi/koizumi_an.asp?id=206398 |
From: Paul H. <pau...@cr...> - 2001-07-06 13:52:46
|
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 |
From: Paul M. <pm...@mv...> - 2001-07-05 19:18:56
|
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. |
From: Frederic S. <fre...@sx...> - 2001-07-05 18:15:47
|
> 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. |
From: Nick B. <ni...@ia...> - 2001-07-05 05:21:09
|
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... |
From: John W. <lin...@ho...> - 2001-07-04 19:53:39
|
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 |
From: Nick B. <ni...@ia...> - 2001-07-04 18:20:06
|
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... |
From: John W. <lin...@ho...> - 2001-07-04 18:09:12
|
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 |
From: Frederic S. <fre...@sx...> - 2001-07-04 15:51:49
|
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. |
From: M. R. B. <mr...@0x...> - 2001-05-24 13:36:47
|
* 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. |