Re: kernel-package rules file patch for UltraSparc
On Sat, Apr 03, 1999 at 01:09:30PM -0400, Steve Dunham wrote:
> 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?)
This is the current devel cvs which is comprised of patches from Dave
Miller and others (judging by the ChangeLog's). Merging with the main
egcs isn't possible since this is not a release source.
> 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.
/lib64 and /usr/lib64 is how egcs compiles by default, so there are no
issues there.
> 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).
Correct.
> (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.)
Right, sparc64 should just be an overlay on top of sparc32. Problems
that will arrise have to do with dpkg/apt/dselect being able to
distinguish prefered builds (ie. prefer an arch=sparc64 over an arch=sparc
of the same package if available) or name the packages with a 64
extension somewhere (which would be horribly difficult to maintain just
for one port).
> > 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 isn't what I am seeing. By init failing I mean the actual binary
/sbin/init. I can get to a single shell as well, but this bypasses init
all together. I also have a kernel compiled without module support, so
it's not directly attributed to modules or module loading. What I see
is init starting and the system hangs right there.
> (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.
I've also tried the 2.2.5 kernel, aswell as the cvs, and still have the
problem. Maybe sparc32-sigaction is a bad thing? The patch looks fairly
innocent.
--
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
OpenLDAP Core - bcollins@openldap.org bcollins@debian.org
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
Reply to: