compiling libc5 on UP1.0

compiling libc5 on UP1.0

[Eiki Ito]

Hi all,

I joined this mailing list recently.  Could someone give me an advice
on how to compile libc?  I'm using Ultrapenguin-1.0 (not 1.0.9).
Eventually I'll move on to 1.0.9, but for now I have to use 1.0 
for a while.  And I have to *compile* it, not just use precompiled one.

o I'm using libc-5.3.12-19.src.rpm found in ultrapenguin-1.0/updates/SRPMS.
 Is this the right package?

o include/asm should point to asm-sparc64, not asm-sparc, correct?

o If I do 'configure' on UP1.0, it says 
  "Build sparc-linux library for sparc64 running linux"
  I don't need to change sparc64 to sparc, do I?

o (**** this is the main question ****)
  Okay, now, when I do 'make depend' (on UP1.0), I get this:

making depend in sparc64
make: Entering an unknown directory
make: *** sparc64: No such file or directory.  Stop.
make: Leaving an unknown directory
make[2]: *** [depend] Error 2
make[2]: Leaving directory `/home/eiki/src/libc-5.3.12-19/libc/sysdeps/linux'

It seems we need sysdeps/linux/sparc64.  Where is it?  sparc/ does not
seem to be an alternative because it needs such things as <psr.h>.

o I boldly went on to 'make' after the failing 'make depend':)  Then this:

getgrgid.c:37: conflicting types for `getgrgid'
.../../include/grp.h:78: previous declaration of `getgrgid'
.../../include/linux/socket.h:89: warning: `cmsg_nxthdr' defined but not used
make[1]: *** [../elfstatic/libc/getgrgid.o] Error 1
make[1]: Leaving directory `/home/eiki/src/libc-5.3.12-19/libc/grp'
make: *** [lib] Error 2

I dunno, apparently I'm missing an important patch or something.

o Oh, BTW, I could compile /sbin/init (statically) on redhat4.2, but
 this one is not useable on UP1.0, is it?  I tried it, but after 
 execve("/sbin/init",..) in init() (in init/main.c) it was stuck.
 Looks like argv/envp was not correctly passed to the user process.

####

Now I'm totally confused with this 32 vs 64 bit stuff...   Is it any
better on 1.0.9?

What I'm trying to do is to port Ultrapenguin to another V9 processor,
our SPARC64-III.  Architecture differences with Ultra should be minimal,
but this is much harder than I thought...  

Thanks,

-------------------------------------
Eiki Ito

HAL Computer Systems, Inc.
1315 Dell Avenue, Campbell, CA95008, USA
e-mail: eiki@hal.com

Re: compiling libc5 on UP1.0

[David S. Miller]

   From: Eiki Ito <eiki@hal.com>
   Date: 	Sat, 9 May 1998 19:20:38 -0700 (PDT)

Firstly, only 32-bit libc's are available at all at the moment.

   o I'm using libc-5.3.12-19.src.rpm found in ultrapenguin-1.0/updates/SRPMS.
    Is this the right package?

yep.

   o include/asm should point to asm-sparc64, not asm-sparc, correct?

nope, it must point to asm-sparc as only a 32-bit userland environment
works at the moment.

   Now I'm totally confused with this 32 vs 64 bit stuff...   Is it any
   better on 1.0.9?

Our goal at the moment is to release a stable 32-bit userland based
UP-1.1  And then finish up the 64-bit userland work we began a long
time ago but only got %70 of the way through.

Firstly, compile the following sparc32.c program, and stick it under /bin:

#include <linux/personality.h>
#include <linux/unistd.h>
#include <stdio.h>
#include <unistd.h>

#ifndef PER_LINUX32
#define PER_LINUX32 8
#endif

_syscall1(int, personality, long, pers);

int main(int argc, char **argv)
{
        if (argc <= 1) {
                fprintf (stderr, "Usage: s32 program arguments\n");
                exit(1);
        }
        personality(PER_LINUX32);
        execvp(argv[1], argv+1);
}

Use it like this:

/bin/sparc32 /bin/sh

This puts you into the 32-bit compilation environment and libc builds
should work just fine.  Actually the only effect this has is to make
uname output "sparc" instead of "sparc64" as the architecture.

   What I'm trying to do is to port Ultrapenguin to another V9
   processor, our SPARC64-III.  Architecture differences with Ultra
   should be minimal, but this is much harder than I thought...  

How easy was it to get the page table guarding and other elements of
the Hal sparc64 chips to work with our memory management and TLB miss
schemes in the kernel?  Can't wait to see this work, feel free to send
patches to me for Hal/V9 support whenever you feel the urge. ;-)

Later,
David S. Miller
davem@dm.cobaltmicro.com

compiling libc5 on UP1.0

[Eiki Ito]

Thanks David for exactly what I wanted!

I wrote:
>o include/asm should point to asm-sparc64, not asm-sparc, correct?
>
>o If I do 'configure' on UP1.0, it says
>  "Build sparc-linux library for sparc64 running linux"
>  I don't need to change sparc64 to sparc, do I?

With these two fixed, it compiled okay.  Next I'll compile
/sbin/init using this libc and try booting again.

>How easy was it to get the page table guarding and other elements of
>the Hal sparc64 chips to work with our memory management and TLB miss
>schemes in the kernel?  Can't wait to see this work, feel free to send
>patches to me for Hal/V9 support whenever you feel the urge. ;-)

SPARC64-III's memory management is quite different from SPARC64-I and II,
much closer to Ultrasparc.  TLB format is (I think) the only major
difference.  No advertise, but if you are interested please refer to
Microprocessor Report 12/08/97.

Sure, I'll send patches when they work or when the system gets shipped,
whichever comes later:)  (Don't ask me when, I'll be fired)

Thanks,

-------------------------------------
Eiki Ito

HAL Computer Systems, Inc.
1315 Dell Avenue, Campbell, CA95008, USA
e-mail: eiki@hal.com

Re: compiling libc5 on UP1.0

[David S. Miller]

   From: Eiki Ito <eiki@hal.com>
   Date: 	Sat, 9 May 1998 20:57:06 -0700 (PDT)

   SPARC64-III's memory management is quite different from SPARC64-I
   and II, much closer to Ultrasparc.  TLB format is (I think) the
   only major difference.  No advertise, but if you are interested
   please refer to Microprocessor Report 12/08/97.

Oh great, finally they are using a software replace TLB miss design in
Hal's sparc64.  You'll benefit greatly from the work I am doing
tonight using virtual page tables, TLB misses cost 8 instructions and
only one memory reference now.

Later,
David S. Miller
davem@dm.cobaltmicro.com