Subject: Simple Linux/MIPS 0.2b

From: Keith M Wesolowski <[email-masked]>
Date: Thu, 13 Jul 2000 00:16:01 -0700

Simple Linux/MIPS 0.2b ``Death on a Stick'' has been released.

*** This is not a production release ***

This version runs on big-endian MIPS systems and has been tested on
R4400 SGI IP22. You can obtain the distribution from the following location:

MANDATORY Release Notes:
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/userland-0.2b/RELEASE_NOTES-0.2b
Binaries:
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/userland-0.2b/bin

There are also some patches in the src/ directory. I have lost some of
my patches but will be recreating them and making them available at
that location as well. Also included is a summary of the commands used
to build the distribution.

Highlights:

- glibc 2.1.90 (000622) based - with empty symbol fix from Maciej
- gcc 2.96 (000707)
- binutils 2.10.90 (000707)
- linux 2.4.0-test3-pre5 (000708)
- support for profiling
- full netkit and net-tools
- gdb 5.0
- ncurses 5.1
- kernel debugging tools
- numerous bugs fixed
- numerous new bugs

Please read the release notes before using. Installation instructions
for 0.1, which should still work in general, can be found at
http://foobazco.org/~wesolows/Install-HOWTO.html.

Thanks to everyone who has been submitting patches, fixing bugs,
writing the software, and in general making this distribution
possible.

This will be the last release for at least 6 weeks. Happy hacking!

-- 
Keith M Wesolowski <[email-masked]> http://foobazco.org/~wesolows/
(( Project Foobazco Coordinator and Network Administrator )) aiieeeeeeee!
"The list of people so amazingly stupid they can't even tie their shoes?"
"Yeah, you know, /etc/passwd."

---

From: "J. Scott Kasten" <[email-masked]>
Date: Thu, 13 Jul 2000 10:58:48 -0300

> Simple Linux/MIPS 0.2b ``Death on a Stick'' has been released.

Fantastic!  I've had great success with release 0.1 on an Indy.  Perhaps
it's almost too stable for my blood.  Need to go play with fire!  ;-)

Actually, I do have a question for any of you that have been doing builds.
I seem to be having some interesting problems with shared object
libraries.  I'm using S-L-M 0.1 on an Indy as a development/test bed for
code that will eventually end up in an embedded vrXXXX system.  (I've
already verified that the binaries are portable.)  However, I am having
difficulty on the Indy itself.  NONE of the shared objects that I build on
that box can be used by programs on that box.  Yes, I either placed them
in /lib or /usr/lib or built a proper ld.so.cache file for them.  The ldd
utility can resolve the libraries, etc...  However, every program built
on that box against libraries that I built on that box exits with an
immediate bus error.  It appears to be an issue with the libraries
themselves.  If I scavenge the equivalent libraries from the Hard Hat 5.1
distro and drop them in place, everything seems happy and works fine.
Thus, there's something funky about the so's I'm building myself.

I've tried building the XFree 4.0.1 libraries, Lesstiff libraries, and
libraries from our own code base.  All breaks the same way.

#1 What form of black magic are you guys using to do this?

#2 Are there specific compiler flags/phases that should/shouldn't be used
with MIPS arch so's that are different than what I'd normally do under
Linux?

#3 Should I be trying to cross compile the so's them selves instead of
native builds?

#4 Are you using different flavors of gcc/binutils to do different jobs
because of known breakages?

Any tips appreciated here.  In the mean, I'm going to start playing with
flags.

Sincerely,

-JSK-

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 14 Jul 2000 00:51:55 +0200

> #1 What form of black magic are you guys using to do this?

Holy Penguin Pee (TM).  Available at www.antarctica.com.br ;-)

> with MIPS arch so's that are different than what I'd normally do under

No compiler flags needed.

> #3 Should I be trying to cross compile the so's them selves instead of

That should make no difference in the resulting binaries if you use the
same versions of everything.

> because of known breakages?

We have various known problems with the various binutils version around.
We're working on getting a current snapshot of binutils working
properly but right now we still have various problems, therefore
egcs 1.0.3a + binutils 2.8.1 is still the recommended version.

  Ralf

---

From: Keith M Wesolowski <[email-masked]>
Date: Thu, 13 Jul 2000 16:30:40 -0700

> that box can be used by programs on that box.  Yes, I either placed them

It's not clear why that is. For example, ncurses is a shared library,
and bash is linked against it. That works fine.

> libraries from our own code base.  All breaks the same way.

I have successfully built XFree on 0.1. It even worked.

> with MIPS arch so's that are different than what I'd normally do under

No.

> #3 Should I be trying to cross compile the so's them selves instead of

If anything that would be worse. It might be faster, though. :)

> because of known breakages?

I'm not because I feel that's a cop-out. If it doesn't work, we need
to fix it, not just keep using old stuff forever as a band-aid. I
don't mean offense to anyone; obviously many people need stability
rather than currency so their take on this will differ from mine; I
just don't believe that using the old toolchain is the right approach
in the long run. It's important to get the -current stuff working and
the only way that will happen is if people find and fix bugs. There
are already a few waiting for some intrepid volunteer to fix; see the
0.2b release notes and various mailing lists. There are known
breakages with binutils, for all versions I am aware of, and for most
if not all gcc versions.  However, for shared libraries and dynamic
linking, the versions included in 0.2b seem to work fine. Ideally the
new toolchain will have _better_ quality than the old one very soon;
when that does, everyone can switch and the ancient stuff can finally
die. In the meantime, consider everything I announce to be of
experimental quality, in case I haven't been adequately clear thus
far.

In the meantime, Ralf and a number of others are using egcs 1.0.3a and
binutils 2.8.1, both with patches. These may be more reliable for you.

> Any tips appreciated here.  In the mean, I'm going to start playing with

Please don't use 0.1 any more. If you want a glibc 2.0 system, use
Hard Hat or some other "officially sanctioned" distribution. Use 0.2b
if you want to play with the current stuff.

Sorry for any confusion.

-- 
Keith M Wesolowski			[email-masked]
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

---

From: "J. Scott Kasten" <[email-masked]>
Date: Thu, 13 Jul 2000 19:39:50 -0300

> egcs 1.0.3a + binutils 2.8.1 is still the recommended version.

OK, I'll give that a shot along with the binutils-000707, gcc-000707 on
the Simple Linux site.  I've disovered that SOME of the shared objects I
build work, some do not at this point using the egcs-1.1.2 and
binutils-2.9.5 from the first Simple release.  I'll keep hammering at
this until I find a combo that does the job.

Thanks.

---

From: "J. Scott Kasten" <[email-masked]>
Date: Thu, 13 Jul 2000 19:59:03 -0300

On Thu, 13 Jul 2000, Keith M Wesolowski wrote:
> > However, I am having

I know, all the other SO's work too, it only seems to affect the ones that
I build, however, I have discovered that some of them do work, but many
don't.

> I have successfully built XFree on 0.1. It even worked.

Well, that's the status that I'm aiming for!

> If anything that would be worse. It might be faster, though. :)

Agreed, however I'm just looking for a solution.

> experimental quality, in case I haven't been adequately clear thus

Again, I agree that is the aproach to take in the long run.  However, my
need is very urgent so I need to find something that works however I have
to do it as I'm attempting to meet a corporate deadline for some
development.

> binutils 2.8.1, both with patches. These may be more reliable for you.

I will evaluate these as I evaluate the tools from the SLM 0.2b release as
well.  The catch I have with gcc-2.96 is that I must have the C++
compiler as well.  But again, I'll figure out what works for me and what
doesn't.  Mainly, I needed to clarify that you guys were not doing
anything special with compiler flags, etc...

> if you want to play with the current stuff.

Well, other than the SO problem, I've had really good luck with that, and
it's really jumpstarted my work quite far.  I've stolen bits and pieces of
what wasn't in there from Hard Hat as needed.  ;-)

I'll be setting up an 0.2b partition soon to evaluate the 2.4.0 kernel and
updated glibc as well at some point.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 19 Jul 2000 16:04:58 +0200 (MET DST)

> egcs 1.0.3a + binutils 2.8.1 is still the recommended version.

 I have binutils 2.10 and gcc 2.95.2 which appear to be stable, i.e. I
haven't observed any problems recently.  I may publish patches if anyone
is interested.  I may see if I can arrange to publish RPM packages as
well.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Hiroshi Kawashima <[email-masked]>
Date: Wed, 19 Jul 2000 23:19:09 +0900

Hi.

In message <[email-masked]>you w
> is interested.  I may see if I can arrange to publish RPM packages as
Great!
Yes, I'm very interested in it.
(Although I'm mipsel (linux-vr) guy, but it will be very helpful.)
----
Kawashima

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 19 Jul 2000 11:54:59 -0300

> is interested.  I may see if I can arrange to publish RPM packages as

Please do.  There's many of us that would be interested.  I for one am
having zero success.

I'm cross posting this from the SGI list to the linuxce list because even
though one is big endian and the other is little endian, we all still use
the same tools, and I simply need help or suggestions here regardless of
the source.

The short explination of what I'm doing is that I work for a company that
wishes to use NEC vr or QED mips processors in some products using linux
as the "embedded OS".  I put quoates on that because our product
environment is much fuller than the traditional embedded environment, to
the point that we actually need a full blown *nix running under the hood.
We plan to run the embedded processors big endian.  We are using some SGI
Indy boxes as development/eval stations at the moment as we evaluate
porting our code base.  The nice thing about the Indy is that the linux
port and user land stuff is still all compiled 32 bit R3000 style, meaning
that its binary compatible with our embedded systems, but a hell of a lot
nicer to work on.  We already know that user space binaries that run on
the Indy work identically within our embeded environment.  That much is
cool.

However, the problem is that I am having only limited success compiling
user space stuff myself on the Indy, be it our own code, or any of the
common distribution libs/apps. I cannot compile shared objects of good
size and expect apps built from them to work.  Xlibs, lesstif, etc and
apps built against them just bus error. However if I go to one of the
sites and tear open a prebuilt rpm for xlibs, or what ever, I can build
against that and get an app to work just fine, but I cannot build the
libraries themselves.  I've tried every version of gcc/egcs/binutils
that's supposed to work, and in every combination.  However, I'm just not
able to duplicate the kind of success that others appear to be having.  
Smaller things usually work.  I've gotten sources from CVS, applied
patches, even tried cross compiling, all to no avail.  Unfortunately, it's
critical that I be able to build things like that.

Anyone that's having good success, please give me some info on what your
build system/process looks like.  I'm completely clueless why I'm not
having the level of success that others appear to be having.

Started with Simple Linux 0.1, glibc-2.0.6, kernel 2.2.14, egcs-1.1.2,
binutils 2.9.5, on Indy 128M ram, R4400SC 200MHz, XL-24.  Have tried the
"manhattan" or "hard hat 5.1" SGI distro, but have never been able to get
that to install.  The 2.1.100 kernel included panics on the Indy due to
page faults in an interupt handler (says so on the screen dump).  Tried
swapping that out for the 2.2.14 kernel from Simle Linux which runs very
stable on that box, but there appears to be a kernel/glibc mismatch at
that point because things don't work right after the boot.  Would like to
try the debian distro, but cannot find a big endian root image to install
with, the site with the eb pacakages seems to be down, and cannot find the
userland utility to unpack the .deb files, so this one is out completely
at the moment.

Have tried native compiles with binutils 2.8.1, egcs-1.0.2, gcc-2.7.2. The
gcc-2.7.2/bin-2.8.1 combo was the closest that I've come.  Was able to
comple lesstif against Xlibs stolen from Hard Hat 5.1 distro and the
programs in the test directory all seemed to work. However, could not get
libs built from XFree86 4.0.1 or CVS to work.  Builds, but everything bus
errors.  Unfortunately, our c++ apps will not compile with g++-2.7.2 even
if that did work.

To clarify, I have no interest in the XServer, just the xlibs so I can
throw output out over the network.

Have also tried cross compiling using binutils 2.8.1 and egcs-1.0.3a on
an x86 box, but still same results.  Little things work, big things just
bus error.

Thanks for any sugestions.  I'm certainly stumped at this point.

---

From: Andy Isaacson <[email-masked]>
Date: Wed, 19 Jul 2000 11:28:11 -0500

> userland utility to unpack the .deb files, so this one is out completely

A .deb file is just an ar(1) archive.  Use "ar xv foo.deb" to unpack.

-andy
-- 
Andy Isaacson <[email-masked]> http://web.mr-happy.com/~adi/

---

From: Keith M Wesolowski <[email-masked]>
Date: Wed, 19 Jul 2000 10:13:50 -0700

> apps built against them just bus error. However if I go to one of the

This is interesting. I have seen plenty of problems (with several
toolchains) building pic objects and then using -static to link. But
linking against shared objects seems to work fine. I have successfully
built the X libs (4.0 + Guido's newport patch) with the toolchain
included in Simple 0.2b, and have run applications linked against
them. The entire system was built from the same toolchain.

> that point because things don't work right after the boot.  Would like to

Could you explain in greater detail? For example, the userland in
Simple 0.2b will not work with kernel < 2.3.51, and will give an
error to that effect if you try to boot it with 2.2.14. This is
intentional; it seems for some reason that glibc 2.2 userland on a 2.2
kernel will have, actually, the kind of behaviour you are observing.

> errors.  Unfortunately, our c++ apps will not compile with g++-2.7.2 even

And unfortunately we still don't have a working c++ compiler for
2.96. Hopefully we're close though.

I almost wonder if your hardware is broken somehow, as the system you
describe is identical in every way to the one I am using to develop
Simple.

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 19 Jul 2000 14:42:15 -0300

> them. The entire system was built from the same toolchain.

I pulled down 0.2b yesterday an will be giving that a whirl today of
course.  However, yes, this problem is interesting.  I've used GDB just
enough on small apps compiled against xlibs/lesstif (things in the lesstif
test directory) to gather limited info on the problem.  Some calls into
the libraries work, however some fail.  I've not isolated the point of
failure, but when it does, the program counter is way off in impossible
memory, and gdb has lost the program call stack so it cannot tell me where
I am, or how I got there.  This behavior is not random, it appears that
it's exactly reproduceable, so with sufficient effort could presumably be
tracked down.  However, my pressing need is simply to get a tool chain
that works within reason.  Although I'm interested in doing some general
sluthing to do my part to improve the quality of publicly available tools,
unfortunately that's a luxury that must wait a little while when you have
corporate deadlines to meet.
 
> kernel will have, actually, the kind of behaviour you are observing.

Simple 0.1 has run very stable for me (meaning no crashes, lockups,
etc...) using the 2.2.14 kernel.  The only problem I have is building my
own shared objects.  I've beat that system for days on end with large
compiles, heavy NFS traffic, etc. and not had it mis-behave.  

I tried booting the 5.1 install image using the included kernel (2.1.100 I
beleive), but it either hangs after initializing eth0, or panics sometime
there after with a "page fault in irq handler" message.

On a whim, I just plunked down 2.2.14 which I know runs smooth and tried
booting the 5.1 install.  I then get a message "Cannot open initial
console."  Yes, the dev nodes are in place and so forth.  Some time ago, I
had gotten past that, but don't remember how.  Anyway, the result was that
things like fdisk could not write the disk and on and on.  This sounds
like a glibc missmatch.  I could try slipping that in too and see what
happens.

In order to move quickly, I had pulled a few libraries from the 5.1 and
plunked them down under Simple to try some things, having checked
dependencies and so forth of course.  I fully admit that such a move could
indeed be part of my problem.  However it's the libraries that I've
stolen in this fashion that work!  Anyway, point is, I've tried moving to
a more complete distro where things have been uniformly compiled with the
same tool chain to see if the shared object problem goes away.  However,
I've not been successfull in that endeavor either.

> 2.96. Hopefully we're close though.

I'd be happy to use different c and c++ compilers, if it worked well.
However, it is of course preferable to remain consistent.  There would
even be an interest in modifying our own C++ code so that templates would
get through g++ 2.7.2 if we had too.  However, it's got to work before we
can make that effort.

> describe is identical in every way to the one I am using to develop

Beleive me, the thought has crossed my mind.  We have 3 identical boxes
that were distributed through our different project teams.  I will
be trying this on one of those minimum as well.

Thanks again for your assistance.

-JSK-

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 19 Jul 2000 19:56:25 -0300

On Wed, 19 Jul 2000, Keith M Wesolowski wrote:
> I have successfully

There is one thing at this point that would really really help.  I need to
establish a reference point and follow someone elses procedures exactly to
determine what the source of my problem is and why some of you are not
seeing this to the extent that I am.  In this way, we can verify whether
or not there is a bonified problem, and if it is with the tools, maybe get
it fixed.

I think the x libs are a good place to start, because I can guarantee that
I'm breaking those, yet you claim to have them working.  I also know that
I can grab someone else's prebuilt and compile against those and get
working apps.  Thus the x libs demonstrate all the "features" of the
problem that I'm encountering.

If you can answer some questions, I can try to parallel what you have
done:

#1  You say you built X using the tool chain for Simple 0.2b.  Does that
mean you compiled it natively on an Indy with what was effectively Simple
0.2b installed?  Or was it cross compiled using the same releases of the
tools?

#2 You say X 4.0.  Can you be more specific?  Was it an official 4.0
tarball on the xfree ftp site?  Pulled from CVS?  Or was it really a
4.0.1?  Basicly, I want the exact same starting sources that you used.

#3 Where can I get Guido's X patch?

#4 What if anything did you add to the host.def or other config files
before doing "make World"?

---

From: Keith M Wesolowski <[email-masked]>
Date: Wed, 19 Jul 2000 18:39:02 -0700

> problem that I'm encountering.

Sure.

> 0.2b installed?  Or was it cross compiled using the same releases of the

It was built natively. You will need to obtain cpp from egcs 1.1.2 and
place it into /lib in order to accomplish this. You can get this at
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/userland-0.2b/bin/cpp

> 4.0.1?  Basicly, I want the exact same starting sources that you used.

It is XFree86 4.0 official + the 000531 version of Guido's patch.

> #3 Where can I get Guido's X patch?

ftp://oss.sgi.com/pub/linux/mips/X/source/newport_000531.diff.gz

> before doing "make World"?

I changed nothing.

---

From: Keith M Wesolowski <[email-masked]>
Date: Wed, 19 Jul 2000 18:51:56 -0700

> or not there is a bonified problem, and if it is with the tools, maybe get

Before you get carried away with this, I should point out that I've
been looking at this problem in more detail. Many of my X programs
don't work either; they get SEGV, never bus errors. I suspect this is
a glibc bug. I can run a few programs, such as xhost and the server
itself. I did have a full X setup, including a working server, under
0.1. That was built exactly the same way I've done it under 0.2b. You
may wish to try both and see which works better.

If you like, I will return to 0.1 and duplicate my previous efforts. I
can then describe the exact procedure to you.

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 19 Jul 2000 22:19:51 -0300

Great.  I'll get in sync with that and see where it takes me.

I did try recompiling our own C++ code on one of the other Indy boxes to
check out the possibility of a hardware problem.  That one was also
running Simple 0.1.  It exhibeted the same bus error.  This alone is not
conclusive one way or another.  That code was developed on x86 and I don't
know if that group ever tested it on Sparc or other risc for
endian/alignment issues in the data structures.  Thus any combination of
the code, compiler, machine could be broken.  Further analysis will tell.

My company seems comitted to using mips, as opposed to moving to any other
arch as I was told to "make it work regardless" this afternoon, even if it
meant changeing their time line a little.  They seem interested in
throwing some people at this if it comes down to fixing the tools to get
the job done.  For arguments sake, if that were the case, what should we
be working with and what people on the mailing lists should I start
getting in touch with?

Thanks again for your input Keith!

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 19 Jul 2000 22:43:35 -0300

> may wish to try both and see which works better.

Alright, that's starting to sound more like what I'm seeing.  Some things
work, some don't.  Some SEGV, some bus error.  The bugs float from one
place to another depending on what tools I used to build.  My litimus test
has been to launch an xterm over the network, xeyes, and xwininfo.  If
those work, then I proceed to building lesstif against that set.
Unfortunately, only libraries that others have built have gotten me to the
lesstif stage.

In fact, I've even had difficulty trying to build the compiler itself
natively.  With egcs-1.03a (patched) it would not natively build using the
egcs-1.1.2, or gcc-2.7.2.  Basicly at the point where the build starts
launching those "genXXXXX" functions, they start segv or bus erroring.
The ones that break depend on which compiler was used.  Thus I was forced
to try that one as a cross compiler, although I just found an rpm for it
so I can finally give it a whirl natively.

> can then describe the exact procedure to you.

Thanks, but not necessary just yet.  I'll try using the X sources and
patch you mentioned on both Simple 0.1 and Simple 0.2b and see what
happens.  We can then compare notes to see what workes, what doesn't.  At
that point I'm confident that we can rule out a lot of the variables and
get down to demonstrating specific problems with the tools themselves.
Also at that point, I can start stuffing the broken binaries into one of
our eval boards and have our hardware people run it against a logic
analyser so we can get to the bottom of some of these things quickly if
they'll let me have the resources.  We're having a staff meeting in the
morning about exactly that. ;-)

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 20 Jul 2000 14:27:47 +0200

> is interested.  I may see if I can arrange to publish RPM packages as

Anyway, have you tried to rebuild an entire Linux distribution with your
toolset, including kernel, static (Like rpm or ldconfig) and dynamic PIC
code?  If that was successful I'd really like to recommend your toolset
as the new standard - especially binutils 2.8.1 are just too rotten.
Example:

[ralf@indy /tmp]$ echo 'main(){}' > c.c;gcc -o c c.c -lm -lieee
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

This nukes binutils 2.8.1 reliably ...  The problem is extracted from the
INN build but also affects a few more packages.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 20 Jul 2000 20:09:41 +0200 (MET DST)

> Yes, I'm very interested in it.

 OK, they are at 'http://www.ds2.pg.gda.pl/~macro/'.

> (Although I'm mipsel (linux-vr) guy, but it will be very helpful.)

 Well, I'm working on a DECstation which is mipsel-linux, so results
should be comparable.  I suppose these fixes work for mips-linux equally
well. 

 I'll see if I can arrange space for RPMs, yet.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 20 Jul 2000 20:57:45 +0200 (MET DST)

> Anyway, have you tried to rebuild an entire Linux distribution with your

 No I didn't and I don't expect anytime soon.  Basically due to the lack
of disk space and time to tweak broken RPMs.  I've effectively build 68 of
different binary RPMs so far (not counting different releases of the same
packages) and these include tools important to run a minimal system as
well as have a reasonable development environment.  These include SysVinit
2.78, bash 2.04, binutils 2.10, db 3.0.55, gcc 2.95.2, gdb 5.0, glibc
2.1.91, pam 0.72, rpm 3.0.4, and others.

> code?  If that was successful I'd really like to recommend your toolset

 As far as I can see both statically (bash.static, rpm, ldconfig) and
dynamically linked code (almost everything else) works.  Dlopening seems
to work as NSS and PAM modules appear to work but it needs further
investigation.  Every recent failure I observed was a result of a bug in
glibc or the kernel. 

> as the new standard - especially binutils 2.8.1 are just too rotten.

 Agreed.

> collect2: ld terminated with signal 11 [Segmentation fault], core dumped

 This works for me with a cross-compiler from an i386 host.  I'll try it
natively at home tonight.  I don't expect a failure, though.  Gcc is
rock-solid for me for quite some time, and the last failure of binutils
I've seen was the problem of relocations in .data section in an executable
I've discussed with Ulf at the end of May.  Gcc 2.96 is just to unstable
to be used unless developing it and there is no point in using binutils
2.10.90 for most people.

> INN build but also affects a few more packages.

 I will build packages progressively but bugfixes and improvements are
higher on my TODO list than a working distribution -- I can work with init
starting bash on the console. ;-)  I hope to have working libpthreads
tonight (fixes are in yesterday's changes and I have a patch to support
R3K) -- this is the last remaining obstacle that prevents me from being
able to build .mipsel.rpm packages natively (not all software cross-builds
well; glibc included).  I'll be able to test various software more
thoroughly then (though building glibc over NFS would certainly not be
running at a stunning speed, sigh...). 

 I will definitely work for getting some FTP space for RPMs.

  Maciej

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 21 Jul 2000 12:21:57 +0200 (MET DST)

> collect2: ld terminated with signal 11 [Segmentation fault], core dumped

 The above example compiles fine for me natively and the resulting binary
works (i.e. it doesn't crash; what else would anyone expect from it? ;-)
).  Also I built a CVS snapshot of glibc 2.1.91 taken Jul 20th, 2000 at
2:25 UTC and it solves the libpthreads showstopper as I expected. 

  Maciej

---

From: Chris Ruvolo <[email-masked]>
Date: Wed, 26 Jul 2000 11:53:04 -0400 (EDT)

On Wed, 19 Jul 2000, J. Scott Kasten wrote:

> Would like to
>with,

I've put one together.  Its rather limited and a bit outdated now (doesn't
have perl 5.005 nor debconf), but you might want to take a look at it.  
It has a working dpkg & apt.  I plan on updating this within the next week
or two.

http://ftp.rfc822.org/pub/local/debian-mips/experimental/debian-mips-base-test_0.3.tar

-Chris

---

From: "J. Scott Kasten" <[email-masked]>
Date: Wed, 26 Jul 2000 14:10:09 -0300

Thanks.  I'll give it a shot in the next few days.