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 <[EMAIL PROTECTED]> Debian GNU/Linux OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED] UnixGroup Admin - Jordan Systems The Choice of the GNU Generation ------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
