🚀 go-pugleaf

Rob Savoye (rob@cygnus.com) wrote:
: loris@caren.demon.co.uk (Loris Caren) writes:

: >This is a good idea but not strictly necessary since what the docs don't 
: >tell you (cos I guess the clever Cygnus/FSF folks think it obvious) is 
: >that an embedded setup is supported by all the flavors (provided the 
: >embedded code doesn't try to make use of the system calls which won't 
: >make much sense).

:   That's one of the reasons we wrote newlib. Newlib is a free libc for embedded
: systems. The system call layer is seperate in the source tree, but it all gets
: built into libc. The only other part is the lowest level I/O code which has
: been moved into a seperate library. This was read, open, etc... (which are
: really system calls) work on whatever target you happen to be on. I've never
: looked at glibc, but newlib works quite well on a large variety of embedded
: systems.

:   As far as the docs go, it's not that we think we're so clever, but like many
: engineers writing docs is our least favorite task, and there never seems to
: be enough time to write stuff down. In a way, the source code is the ultimate
: documentation, so that's where the time goes. 

Well...I assume the patches from the cygnus site you were referring to were
called crossgcc-2.6.0.patch.gz.  I've picked these up and will be trying them
out today.

This somewhat underscores the problem I've been having though, one person
says build GCC for sun3 and GAS/LD for coff/aout.  Another person says that
won't work.   Another says you need patches from some site but when you look
at that site it has no decent index/table of contents.  One part of a document
says that on a particular system you must use GLD if you use GAS and then
later goes on to say you must use GAS with the local linker if you want
debugging support.

The problem is that many documents do not agree and while some very complex
topics are pretty well covered, many of the simpler ones are barely touched
on at all.

I've been a software engineer for something like 20 years now and am not
inexperienced in building programs.  The problem is that when presented
with something like 20 meg of sources and docs it's very easy to miss
the file that has the information you want if it isn't CLEARLY marked.

I understand that it's a pain to write documentation, god knows I hate
it myself, but sometimes not much is really required.  As they used to
say "most magic tricks are easy once you know the secret".  If distributors
would include even a simple pointers file with their stuff it would be
very helpful and save people tons of time.  For example, a file with
lines like "if you want information on X, look here.  If you want to build
a cross compiler you need these 4 packages...etc."  Basically the standard
FAQ format with a paragraph or so giving pointers to where in the sources
or documents fairly important info can be found.

Anyway, I'm not trying to start an argument or flame anyone in particular
(honest).  But while I've been trying to get my cross compiler up I've
been running into a lot of people that have similar, seemingly not
terribly complicated, questions.  A few problems I've run into on my
free software quests have been answered by less than a paragraph, sometimes
even a sentence ("oh...look at this file (one out of 500) for the answer").

If we're going to avoid frustrating people like crazy we need to start
collecting the answers to problems like these.  Pasting them all into
a big file and then getting the distributors of these software packages
(ie: people like FSF) to include the help files or make them easily available.

It's still fairly common to log on to a ftp site and find no description
at all of the files found there, or having to hunt like crazy for it.
It would be great if people running sites could provide even a single
line of text description for each file.  Aside from helping people
find what they want, this would also reduce load on sites by reducing
occurances of people downloading what they THINK is what they want and
then discovering they guessed wrong and having to download another guess.

Anyway...If I do finally get this cross compiler of mine working...I will
take the time to type up how it was done and post it here.  And I'm willing
to bet the procedure will be less than a page of text.

Greg Corson
milo@mcs.com