SILO 1.4.10

SILO 1.4.10

[Ben Collins]

Been a long time coming. This mainly includes:

- Fix for printing banner
- Fix for allocation of initrd memory region on some memory layouts
(patch from davem)

There's a few other minor tweaks, like building on current systems
(gcc/libc/libext2 changes).

http://www.sparc-boot.org/pub/silo/

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Jim Gifford]

Can't get this to build under GCC 4.0.2, Binutils 2.16.1, and Glibc
2.3.6. Any idea's.

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Ben Collins]

On Mon, 2006-01-02 at 13:34 -0800, Jim Gifford wrote:
> Can't get this to build under GCC 4.0.2, Binutils 2.16.1, and Glibc
> 2.3.6. Any idea's.

Builds for me with gcc-4.0.2, binutils 2.16.91, glibc 2.3.5.

Maybe posting your build error would help.

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Tom 'spot' Callaway]

On Mon, 2006-01-02 at 13:34 -0800, Jim Gifford wrote:
> Can't get this to build under GCC 4.0.2, Binutils 2.16.1, and Glibc
> 2.3.6. Any idea's.

While not directly related to your failure (you should paste the actual
build failure if you'd like anyone to try to fix it), I can confirm that
1.4.10 builds with GCC 3.4.2, Binutils 2.16.91.0.3, and Glibc 2.3.3.

Haven't booted it yet though, but it built! (To be fair, I've had no
problems building silo for some time)

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

Re: SILO 1.4.10

[Jim Gifford]

The problem is that there is no build error, but it just gives me an 
error message when I run silo -f.

# silo -f
/etc/silo.conf appears to be valid
Fatal error: Corrupted /boot/second.b or second stage with incorrect version


-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Ben Collins]

On Mon, 2006-01-02 at 14:12 -0800, Jim Gifford wrote:
> The problem is that there is no build error, but it just gives me an 
> error message when I run silo -f.
> 
> # silo -f
> /etc/silo.conf appears to be valid
> Fatal error: Corrupted /boot/second.b or second stage with incorrect version

Works fine for me. Try this:

cp first/{first,ultra,generic}.b /boot
cp second/second.b /boot
cp silo/silo /sbin/silo

silo -f


If that fails, then something is seriously wrong with your second.b
image.

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Jim Gifford]

The same exact thing.

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Ben Collins]

On Mon, 2006-01-02 at 14:51 -0800, Jim Gifford wrote:
> The same exact thing.

You are compiling stock source? I can't see binutils causing this
problem. Maybe it's elftoaout, but I've never seen anyone get it
compiled only to have it spit out that message.

You'll need to dig into this yourself. Use hexedit and see what's up
with second.b

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Jim Gifford]

I verified the only file not being built correctly is second.b. I used 
hexdump to create a hexdump of the second.b from silo-loaders-1.4.10 and 
the one I compiled. It looks like everything is shifted.

http://ftp.jg555.com/diff_of_hex_dump

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Ben Collins]

On Mon, 2006-01-02 at 16:00 -0800, Jim Gifford wrote:
> I verified the only file not being built correctly is second.b. I used 
> hexdump to create a hexdump of the second.b from silo-loaders-1.4.10 and 
> the one I compiled. It looks like everything is shifted.
> 
> http://ftp.jg555.com/diff_of_hex_dump

Are you compiling this as 64-bit or 32-bit? All I know is this has to be
something with your toolchain. I've compiled this just fine with several
compilers and several binutils (gcc-3.4, gcc-4.0).

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Jim Gifford]

Building 32bit on a multilib system. Here's a complete link to the 
complete build log

http://ftp.jg555.com/silo_build.log

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Ben Collins]

On Mon, 2006-01-02 at 18:53 -0800, Jim Gifford wrote:
> Building 32bit on a multilib system. Here's a complete link to the 
> complete build log
> 
> http://ftp.jg555.com/silo_build.log

ld -N -Ttext 0x280000 -Bstatic -o second crt0.o
decomp.o ../common/console.o ../common/printf.o
malloc.o ../common/jmp.o ../common/prom.o ../common/tree.o ../common/urem.o ../common/udiv.o ../common/stringops1.o ../common/ffs.o ../common/divdi3.o ../common/udivdi3.o bmark.o main.o cmdline.o disk.o file.o misc.o cfg.o strtol.o ranges.o timer.o memory.o fs/libfs.a mul.o ../common/rem.o ../common/sdiv.o umul.o ../common/stringops2.o ls.o muldi3.o -lext2fs mark.o
ld: warning: sparc:v8plus architecture of input file `crt0.o' is incompatible with sparc:v9 output
ld: warning: sparc architecture of input file `decomp.o' is incompatible with sparc:v9 output
ld: warning: sparc architecture of input file `../common/console.o' is incompatible with sparc:v9 output

Your linker is defaulting to elf64_sparc. Edit Rules.make, and make LD=ld -m elf32_sparc
-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux

Re: SILO 1.4.10

[Jim Gifford]

When I do that, I get the same problem. Also when the -m elf32_sparc is 
there, all the other files are different.

 cmp /boot/fd.b fd.b
/boot/fd.b fd.b differ: char 1, line 1

Which made me thing there was something else wrong elsewhere, I rebuild 
elftoaout as 32bit, and now everything works.

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Jim Gifford]

Further testing is showing the elftoaout built as 64bit will create all 
the files except for second.b correctly. Which is kinda of wierd.

Further testing when compiled silo as 64 bit(just did it to see) the 
same issue only second.b is not created properly. Compared to the 32 bit 
build the .b files are the same except for second.b.

So we have 2 potential issues

1 - elftoaout is not creating proper files when it's compiled as 64bit
2 - second.b is not being created properly

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[David S. Miller]

From: Jim Gifford <maillist@jg555.com>
Date: Tue, 03 Jan 2006 09:39:19 -0800

> So we have 2 potential issues
> 
> 1 - elftoaout is not creating proper files when it's compiled as 64bit
> 2 - second.b is not being created properly

It's probably just some 64-bit arithmatic coding error
in elftoaout that only gets triggered by the second.b
image and not by most other uses of the utility.

Someone with the time and inclination can probably look
at the final image differences, and use that to pinpoint
the elftoaout problem when built 64-bit.

Re: SILO 1.4.10

[David S. Miller]

From: Jim Gifford <maillist@jg555.com>
Date: Tue, 03 Jan 2006 09:39:19 -0800

> 1 - elftoaout is not creating proper files when it's compiled as 64bit

I actually did the investigation and elftoaout cannot work
ever when built 64-bit.  It defines the member types of the
A.OUT header structure as "unsigned long" which is 64-bit
when compiled 64-bit, it needs to be 32-bits in size.

Please try this patch:

--- elftoaout.c.~1~	2000-06-03 13:20:12.000000000 -0700
+++ elftoaout.c	2006-01-03 13:36:06.000000000 -0800
@@ -20,16 +20,36 @@
  */
 #include <stdio.h>
 #include <stdlib.h>
-#ifdef linux
 #include <linux/elf.h>
-#define ELFDATA2MSB   2
-#else
-#include <sys/elf.h>
-#endif
-
-#define swab16(x)  (((x)<<8&0xFF00)|((x)>>8&0x00FF))
-#define swab32(x)  (((x)<<24&0xFF000000)|((x)<<8&0x00FF0000)|((x)>>24&0x000000FF)|((x)>>8&0x0000FF00))
-#define swab64(x)  ((((unsigned long long)(swab32((unsigned int)x))) << 32) | (swab32(((unsigned long long)x)>>32)))
+#include <sys/types.h>
+
+static inline u_int16_t swab16(u_int16_t x)
+{
+	return (((x << 8)  & 0xFF00) |
+		((x >> 8) & 0x00FF));
+}
+
+static inline u_int32_t swab32(u_int32_t x)
+{
+	return (((x << 24) & 0xFF000000) |
+		((x <<  8) & 0x00FF0000) |
+		((x >> 24) & 0x000000FF) |
+		((x >>  8) & 0x0000FF00));
+}
+
+static inline u_int64_t swab64(u_int64_t x)
+{
+	return ((u_int64_t)
+	((u_int64_t)(((u_int64_t)x & (u_int64_t)0x00000000000000ffULL) << 56) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x000000000000ff00ULL) << 40) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x0000000000ff0000ULL) << 24) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x00000000ff000000ULL) <<  8) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x000000ff00000000ULL) >>  8) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x0000ff0000000000ULL) >> 24) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0x00ff000000000000ULL) >> 40) |
+	 (u_int64_t)(((u_int64_t)x & (u_int64_t)0xff00000000000000ULL) >> 56)));
+}
+
 
 /* We carry a.out header here in order to compile the thing on Solaris */
 
@@ -37,14 +57,14 @@
 #define	CMAGIC	    0x01030108
 
 typedef struct {
-	unsigned long	a_magic;	/* magic number */
-	unsigned long	a_text;		/* size of text segment */
-	unsigned long	a_data;		/* size of initialized data */
-	unsigned long	a_bss;		/* size of uninitialized data */
-	unsigned long	a_syms;		/* size of symbol table || checksum */
-	unsigned long	a_entry;	/* entry point */
-	unsigned long	a_trsize;	/* size of text relocation */
-	unsigned long	a_drsize;	/* size of data relocation */
+	u_int32_t	a_magic;	/* magic number */
+	u_int32_t	a_text;		/* size of text segment */
+	u_int32_t	a_data;		/* size of initialized data */
+	u_int32_t	a_bss;		/* size of uninitialized data */
+	u_int32_t	a_syms;		/* size of symbol table || checksum */
+	u_int32_t	a_entry;	/* entry point */
+	u_int32_t	a_trsize;	/* size of text relocation */
+	u_int32_t	a_drsize;	/* size of data relocation */
 } Exec;
 
 
@@ -56,17 +76,16 @@
 	int swab;
 	int sparc64;
 	int csum;
-	/* friend void Usage(void); */
 } Application;
 
 typedef struct {
 	Elf32_Phdr *tab;
-	unsigned len;
+	unsigned int len;
 } ProgTable;
 
 typedef struct {
 	Elf64_Phdr *tab;
-	unsigned len;
+	unsigned int len;
 } ProgTable64;
 
 void get_ptab(ProgTable *t, FILE *inp, const Elf32_Ehdr *h);
@@ -75,9 +94,9 @@
 void print_ptab64(ProgTable64 *t);
 
 typedef struct {
-	char *buf;                /* Image data */
-	unsigned len;             /* Length of buffer */
-	unsigned bss;             /* Length of extra data */
+	unsigned char *buf;       /* Image data */
+	unsigned int len;         /* Length of buffer */
+	unsigned int bss;         /* Length of extra data */
 } Segment;
 
 void load_image(Segment *t, const ProgTable *h, FILE *inp);
@@ -105,7 +124,8 @@
 
 	parse_args(&prog, argc, argv);
 
-	if (prog.version) Version();
+	if (prog.version)
+		Version();
 
 	if (freopen(prog.iname, "r", stdin) = NULL) {
 		fprintf(stderr, "Cannot open \"%s\"\n", prog.iname);
@@ -141,7 +161,8 @@
 	exit(0);
 }
 
-void parse_args( Application *t, unsigned argc, const char **argv ){
+void parse_args( Application *t, unsigned argc, const char **argv )
+{
 	const char *arg;
 	union {
 		char c[4];
@@ -185,8 +206,8 @@
 	if (t->csum && t->sun4_mode) Usage ();	/* Checksum lives in header. */
 }
 
-void get_header(Elf32_Ehdr *t, FILE *inp) {
-
+void get_header(Elf32_Ehdr *t, FILE *inp)
+{
         if (fread((void*) t, sizeof(Elf64_Ehdr), 1, inp) != 1) {
 		fprintf(stderr, "Read error on header\n");
 		exit(1);
@@ -249,8 +270,9 @@
 	}
 }
 
-void get_ptab(ProgTable *t, FILE *inp, const Elf32_Ehdr *h) {
-	unsigned x;
+void get_ptab(ProgTable *t, FILE *inp, const Elf32_Ehdr *h)
+{
+	unsigned int x;
 
 	/** fprintf(stderr, "Program header table off = 0x%x\n",
 		(unsigned) h->e_phoff); **/
@@ -294,8 +316,9 @@
 	}
 }
 
-void get_ptab64(ProgTable64 *t, FILE *inp, const Elf64_Ehdr *h) {
-	unsigned x;
+void get_ptab64(ProgTable64 *t, FILE *inp, const Elf64_Ehdr *h)
+{
+	unsigned int x;
 
 	if (h->e_phoff = 0) {
 		fprintf(stderr, "No Program Header Table\n");
@@ -332,8 +355,9 @@
 	}
 }
 
-void print_ptab(ProgTable *t) {
-	unsigned x;
+void print_ptab(ProgTable *t)
+{
+	unsigned int x;
 	const Elf32_Phdr *p;
 
 	for (x = 0; x < t->len; x++) {
@@ -374,8 +398,9 @@
 	}
 }
 
-void print_ptab64(ProgTable64 *t) {
-	unsigned x;
+void print_ptab64(ProgTable64 *t)
+{
+	unsigned int x;
 	const Elf64_Phdr *p;
 
 	for (x = 0; x < t->len; x++) {
@@ -387,8 +412,11 @@
 			break;
 		case PT_LOAD:
 			printf("Loadable to 0x%Lx[0x%Lx] from 0x%Lx[0x%Lx] align 0x%Lx",
-				p->p_vaddr, p->p_memsz, p->p_offset, p->p_filesz,
-				p->p_align);
+			       (unsigned long long) p->p_vaddr,
+			       (unsigned long long) p->p_memsz,
+			       (unsigned long long) p->p_offset,
+			       (unsigned long long) p->p_filesz,
+			       (unsigned long long) p->p_align);
 			break;
 		case PT_DYNAMIC:
 			printf("Dynamic");
@@ -416,9 +444,10 @@
 	}
 }
 
-void load_image(Segment *t, const ProgTable *tp, FILE *inp) {
+void load_image(Segment *t, const ProgTable *tp, FILE *inp)
+{
 	Elf32_Phdr *p, *q;
-	unsigned x;
+	unsigned int x;
 	unsigned long off, len;
 
 	p = 0;
@@ -484,9 +513,10 @@
 	}
 }
 
-void load_image64(Segment *t, const ProgTable64 *tp, FILE *inp) {
+void load_image64(Segment *t, const ProgTable64 *tp, FILE *inp)
+{
 	Elf64_Phdr *p, *q;
-	unsigned x;
+	unsigned int x;
 	unsigned long long off, len;
 
 	p = 0;
@@ -547,7 +577,8 @@
 	}
 }
 
-void store_image(Segment *t, FILE *out) {
+void store_image(Segment *t, FILE *out)
+{
 	Exec ohdb;
 
 	if (prog.swab) {
@@ -585,13 +616,15 @@
 	return;
 }
 
-void Usage(){
+void Usage()
+{
 	if (prog.version) Version();
 	fprintf(stderr, "Usage: elftoaout [-o output] [-c|-b] [-V] input\n");
 	exit(1);
 }
 
-void Version(){
+void Version()
+{
 	printf("elftoaout 2.3: ELF to a.out convertor for SPARC and SPARC64 bootstraps\n");
 }
 

Re: SILO 1.4.10

[Richard Mortimer]

On Tue, 2006-01-03 at 12:50 -0800, David S. Miller wrote:
> From: Jim Gifford <maillist@jg555.com>
> Date: Tue, 03 Jan 2006 09:39:19 -0800
> 
> > So we have 2 potential issues
> > 
> > 1 - elftoaout is not creating proper files when it's compiled as 64bit
> > 2 - second.b is not being created properly
> 
> It's probably just some 64-bit arithmatic coding error
> in elftoaout that only gets triggered by the second.b
> image and not by most other uses of the utility.
> 

I just took at quick look at the Debian elftoaout sources and the a.out
Exec header definition uses unsigned long to hold the values. These will
have the wrong size when compiled 64 bit. I tried changing it to
unsigned int and the 64 bit version now produces the same output as the
32 bit one when tested against a vmlinux that I had hanging around.

Patch below.

Richard

--- sparc-utils-1.9/elftoaout-2.3/elftoaout.c.orig      2006-01-03 21:11:05.000000000 +0000
+++ sparc-utils-1.9/elftoaout-2.3/elftoaout.c   2006-01-03 21:16:20.000000000 +0000
@@ -37,14 +37,14 @@
 #define        CMAGIC      0x01030108

 typedef struct {
-       unsigned long   a_magic;        /* magic number */
-       unsigned long   a_text;         /* size of text segment */
-       unsigned long   a_data;         /* size of initialized data */
-       unsigned long   a_bss;          /* size of uninitialized data */
-       unsigned long   a_syms;         /* size of symbol table || checksum */
-       unsigned long   a_entry;        /* entry point */
-       unsigned long   a_trsize;       /* size of text relocation */
-       unsigned long   a_drsize;       /* size of data relocation */
+       unsigned int    a_magic;        /* magic number */
+       unsigned int    a_text;         /* size of text segment */
+       unsigned int    a_data;         /* size of initialized data */
+       unsigned int    a_bss;          /* size of uninitialized data */
+       unsigned int    a_syms;         /* size of symbol table || checksum */
+       unsigned int    a_entry;        /* entry point */
+       unsigned int    a_trsize;       /* size of text relocation */
+       unsigned int    a_drsize;       /* size of data relocation */
 } Exec;





-- 
Richard Mortimer <richm@oldelvet.org.uk>

Re: SILO 1.4.10

[David S. Miller]

From: Richard Mortimer <richm@oldelvet.org.uk>
Date: Tue, 03 Jan 2006 21:52:07 +0000

> I just took at quick look at the Debian elftoaout sources and the a.out
> Exec header definition uses unsigned long to hold the values. These will
> have the wrong size when compiled 64 bit. I tried changing it to
> unsigned int and the 64 bit version now produces the same output as the
> 32 bit one when tested against a vmlinux that I had hanging around.
> 
> Patch below.

Right, I just posted a similar patch using u_int{8,16,32,64}_t and
friends.

Re: SILO 1.4.10

[Jim Gifford]

Dave,
    Your patch did the trick. Thank you.

-- 
----
Jim Gifford
maillist@jg555.com

Re: SILO 1.4.10

[Jim Gifford]

Richard,
    Your patch also works. Thank you

-- 
----
Jim Gifford
maillist@jg555.com

Silo 1.4.10

[Joe Ciccone]

I have been working on a patch for silo that would enable me to build it in a pure64 bit enviornment. The patch is of my current working tree. The .b files build properly with this patch, It creates a static libext2fs that I put together myself and then uses that instead of the system libext2fs library which is only available in 64bit in this setup. The loaders are built 32bit and the rest of the programs are built 64bit. This is done with a modification to Rules.make by creating a CC (for host tools) and CC-SILO (for always 32bit parts). This setup relies on the fact that you have a working elftoaout binary, this was discussed earlier on this list, if you would like me to provide the patch please let me know. The include directory after this patch is applied is so large because I have copied headers from my 32bit build. CC-SILO is instructed not to use any headers from the system. This fixes and issue in the building of the .b files, which should have never included any of the system headers in the first place. I think I've traced down the problem to silo.c because before I run silo -f the .b files from my successful installation are identical to the loaders in this setup. When the table in the top of second.b is generated with silo -f, it doesn't seem to be right. I have one request, Don't say silo doesn't work on 64bit only systems. I am looking for some assistance in fixing this issue. The patch I have attached is a Major head start for anyone who has tried this in the past. I apreciate any help I can get on making this work, I've spent a lot of time on this already but I don't understand the inner workings of the silo program.

The Silo-1.4.10 patch is http://www.crazyeyesoft.com/Silo-1.4.10-fixes-2.patch

Re: Silo 1.4.10

[David S. Miller]

Please tech your email client to add newlines every 80 characters
or something like that.  It's very painful to read an entire paragraph
of several hundred characters without a single intervening newline.

People will see you as a newbie and a charlatan with emails that look
like that, and may thus decide to ignore your valuable contributions
as a result.

Re: Silo 1.4.10

[Joe Ciccone]

I'm sorry about my client not wrapping its lines at 80 characters
before, I had the wrong text format selected.

I have been working on a patch for silo that would enable me to build it
in a pure64 bit enviornment. The patch is of my current working tree.
The .b files build properly with this patch, It creates a static
libext2fs that I put together myself and then uses that instead of the
system libext2fs library which is only available in 64bit in this setup.
The loaders are built 32bit and the rest of the programs are built
64bit. This is done with a modification to Rules.make by creating a CC
(for host tools) and CC-SILO (for always 32bit parts). This setup relies
on the fact that you have a working elftoaout binary, this was discussed
earlier on this list, if you would like me to provide the patch please
let me know. The include directory after this patch is applied is so
large because I have copied headers from my 32bit build. CC-SILO is
instructed not to use any headers from the system. This fixes and issue
in the building of the .b files, which should have never included any of
the system headers in the first place. I think I've traced down the
problem to silo.c because before I run silo -f the .b files from my
successful installation are identical to the loaders in this setup. When
the table in the top of second.b is generated with silo -f, it doesn't
seem to be right. I have one request, Don't say silo doesn't work on
64bit only systems. I am looking for some assistance in fixing this
issue. The patch I have attached is a Major head start for anyone who
has tried this in the past. I apreciate any help I can get on making
this work, I've spent a lot of time on this already but I don't
understand the inner workings of the silo program.

The Silo-1.4.10 patch is
http://www.crazyeyesoft.com/Silo-1.4.10-fixes-2.patch

Re: Silo 1.4.10

[Ben Collins]

On Fri, 2006-02-10 at 19:32 -0500, Joe Ciccone wrote:
> I have been working on a patch for silo that would enable me to build it
> in a pure64 bit enviornment. The patch is of my current working tree.
> The .b files build properly with this patch, It creates a static
> libext2fs that I put together myself and then uses that instead of the
> system libext2fs library which is only available in 64bit in this setup.
(cut)

What's the deal with all the system headers you pulled in? Those things
should be in the userspace toolchain, and not in the SILO package
itself. If you are having issues with 64-bit vs. 32-bit asm headers,
please check how most of the sparc dists are handling that (dummy
headers in /usr/include/asm that point to asm-sparc{,64} depending on
__arch64__ being defined).

Aside from that it looks ok. Please clean it up, and I can include it
for the next SILO release.

-- 
Ben Collins
Kernel Developer - Ubuntu Linux

Re: Silo 1.4.10

[Joe Ciccone]

This task is finally over. The link to the following patch is as minimal
as i think it can be giving the structure of silo. /include/emul_32
contains asm headers that control the types, This was what i was after
when I pulled in all of the system headers. CC is split up into CC and
CC-SILO, CC builds default to whatever the host is, and CC-SILO will
always build 32bit ensuring that the loaders are properly built. This
patch has been tested by myself on a multilib pure64 build and by one
other person on a pure64 build. Enjoy a 32bit less machine! - Joe

http://www.crazyeyesoft.com/silo-1.4.10-fixes-2.patch
-or-
http://www.linuxfromscratch.org/patches/downloads/silo/silo-1.4.10-fixes-2.patch