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