[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-package rules file patch for UltraSparc

Ben Collins <bcollins@debian.org> writes:

> On Sat, Apr 03, 1999 at 11:02:09AM -0400, Steve Dunham wrote:
> > Argh.  Forgot about that. Bug in egcs64 package that I fixed locally
> > with a symlink.  I'll add this to the egcs64 package if I can't find a
> > better solution.
> >
> >   install -d /usr/sparc-linux
> >   ln -s ../lib /usr/sparc-linux/lib
> >
> > A bug report should be filed against egcs64, if it hasn't been filed
> > already.

> While on the topic of egcs64, I'm about to upload a newer one based on
> the latest egcs cvs (I'll trim the source as much as possible). It
> compiles the kernels still, better yet I actually have a 64bit libc.a
> (glibc 2.1.1pre1) and compiled a simple source file with and it works.
> Dynamic libraries aren't working due to a lack in a certain part of
> egcs's TARGET_ARCH64 defines. The main difference is that this is
> compiled as a cross sparc32->sparc64 compiler.

Ok, a couple of issues here:

  When we make a proper sparc64 egcs cross compiler, we're supposed to
  merge it in with the main egcs package.  I think Espy is the person
  to talk to. (The reason I made egcs64 was that special patches were
  needed to get it to compile the kernel, and I wasn't sure the
  current upstream version would work - is the stock upstream source
  able to compile a working kernel now?)

  We need to maintain compatibility with UltraPenguin - these are the
  people actually doing much of the work. They are going to use a
  lib64 directory for 64-bit libraries (patches should be in the
  UltraPenguin egcs/binutils source packages).  Somebody needs to look
  into this.

  That said, if the stuff is starting to work, we should definitely
  try to get the appropriate patches into the egcs, binutils, and
  glibc packages (glibc will have to patch to have to be patched to
  build a seperate 64-bit library package, when requested, and stick
  it in /lib64 resp. /usr/lib64).

  (See attached message.)

  IMHO, we sould follow their lead, and go with a hybrid 32-/64-bit
  system.  This way:

     * Programs that need 64 bits can be compiled as such.
     * Programs that don't need it don't incur the performance 
       penalty of extra code/data size.
     * We don't have to recompile everything.  (If we completely split
       into sparc and sparc64 dists, it will be even harder to keep
       the packages in sync with the other archs.)

> I'm still working on this. I'm also wondering if anyone has anymore
> feedback on glibc 2.1.1 on non-sun4u systems. I am still unaware of
> what is causing init to fail, and still haven't gotten my 1+ setup so
> am unable to test it right now. Until we get that solved we are stuck
> with 2.0.105.

init isn't failing on my system.  (I can boot to a single user shell.)
The problems were with kernel module loading, which for some reason,
are triggered by the gpm and xdm init scripts.

(This is with a 2.2.1 kernel. I'm having problems with a 2.2.5 kernel
not taking input at the sulogin prompt - I suspect this is because I
need to moount devpts.  I'm booting a tftp image to fix this right now.)

I don't see this problem in RawHide, and it doesn't look like they
have any special patches in the modutils or glibc packages.  Although
we do have a patch that they don't have.  (sigaction)

The library that I compiled myself (just added your chown patch) still
had the problem.

Attachment: lib64.txt
Description: Binary data

Reply to: