Re: Document / Script for automating cross-compiler build

Re: Document / Script for automating cross-compiler build

[David Williams]

Thanks for the script. I have used an earlier version of the script you
posted and
was eventually, with just a few minor hiccups able to compiler for
m68k-coff. I
will be trying m68k-elf soon.

I am using latest cygwin net release 1.1.4 on Win98SE (Celeron 533). The
first
problem I had was that my user name was "David Williams". The space in
the name
seemed to cause a lot of problems. I changed it to just "Dave" and it
worked much
better. The first time I attempted to compile I had the build directory
outside of
the root directory for cygwin, ie somewhere else in the windows
directory
structure and I got problems building binutils and then GCC. The next
time I tried
it I put the build directory inside my home directory and this seemed to
work ok.
It took about 3 hours to compile the lot. I am not sure if I had fixed
my user
name when trying to build the first time.

A couple of questions

The compiler that is built seems to not output line terminators in the
verbose
output (as it use to). I end up with very long lines of verbose (-v)
information
from the compiler. I have been using V6 of David Fiddes coldfire
binaries (ECGS
1.1.2) and the output of verbose information in that was fine. Where
should I
start looking?

Why should I prefer elf to coff for an m68k embedded target?

I was examining your script to determine what things it does so that I
can build
individual pieces of the system as required. More specifically I think I
will need
to modify some functions in newlib and was wondering how that was built.
I could
not see any specific commands that built newlib so I assume that the
--with-newlib
option when building GCC also causes newlib to be built. Can you confirm
this? How
would I just build newlib?

Dave.

Christopher Bahns wrote:

> Hello All,
>
> Attached is a script that is intended to make the building of a
> cross-compiler under Windows 95/98/NT and Cygwin 1.1.x as easy and
> automated as possible. I don't know if it would be just as useful to
> non-Windows people, but I suspect it might be (with some modification
> perhaps). But, it is intended for Windows/Cygwin people.
>
> I had a lot of trouble getting compiler builds to work on my SMP
> dual-Celeron system running Windows NT 4.0 Workstation. If anyone has
> success on an SMP system using Cygwin 1.1.x, please let me know.
>
> The script starts from scratch and assumes that you have nothing except
> a computer running Windows NT or 98 (95 should work too, but don't know
> about 2000). Unfortunately the only editor you will end up having
> available in the Cygwin environment is vi. I prefer Emacs, and have
> built and installed XEmacs on my machine, but this is not included in
> the attached script. You also will not have the benefit of perl or info.
> I really wish Cygnus/RedHat will include at least these three tools in
> future releases of its Cygwin environment.
>
> The script also includes some advice on what all you need to get an
> embedded program linked and running properly. Although I'm far from an
> expert on this, I have gotten my program to run on my M68306-based
> device, and I include in the script's comments some of the things I had
> to do to get to that point..
>
> Please let me know if this is helpful, or if you have recommendations
> for changes/additions, or whether a similar thing already exists for us
> unfortunate Windows people and I just could not find it.
>
> The script is currently configured as follows (based on what I needed),
> but is designed in a way to make these things easy to change:
>     Target: m68k-coff
>     Prefix: /gcc-m68k
>     binutils-2.10
>     gcc-2.95.2
>     newlib-1.8.2
> I have also done successful builds with the Target set to "m68k-elf".
>
> Chris
>
>   ------------------------------------------------------------------------
>                       Name: buildgcc.tar.gz
>    buildgcc.tar.gz    Type: Winzip32 File (application/x-winzip)
>                   Encoding: base64
>
>   ------------------------------------------------------------------------
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Document / Script for automating cross-compiler build

[Matt Minnis]

<Snip>

> > Why should I prefer elf to coff for an m68k embedded target?

Because the commercial debugging vendors don't support Coff at all.  Elf or 
IEEE695 (some) are the formats that they use.  Elf provides more complete 
dbug information than Coff.

I am not sure what the other reasons are.

Hope this helped.

Matt Minnis

Cthulhu for President. Why settle for a lesser evil?

=========================================================
Preferred Resources          (314) 567-7600 phone
701 Emerson rd.              (314) 993-6699 fax
Suite 475		       mminnis@prefres.com
St. Louis, MO
63141
=========================================================


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Document / Script for automating cross-compiler build

[Christopher Bahns]

David Williams wrote:

> The compiler that is built seems to not output line terminators in the verbose
> output (as it use to). I end up with very long lines of verbose (-v) information
> from the compiler. I have been using V6 of David Fiddes coldfire binaries (ECGS
> 1.1.2) and the output of verbose information in that was fine. Where should I
> start looking?
>

Don't know anything about this. I have not used the -v option... don't know why it
would not work. (Maybe I'll look at that later.)

> Why should I prefer elf to coff for an m68k embedded target?

I'd like to know the answer to this myself. ELF is newer (so it must be better,
right?). I would assume that any new emulators/simulators/debugging tools that get
information from object files might either only work with ELF or at least work better
with ELF. I believe that ELF provides support for shared objects (like DLLs), whereas
COFF does not (I could be wrong), but this would not matter for embedded stuff I
imagine.

I'd like to use ELF right now, since I'm afraid I'll want to move to it later (for
whatever reason I'm not sure right now), but I'm having trouble with section
alignment. I did have trouble with section alignment using COFF, but got it
straightened out. At the moment I do not seem to be able to control section alignment
with ELF as well, but have more investigation to do there.

I think Kai Ruottu had some helpful advice about this a while ago, but I forget what
he said.

> I was examining your script to determine what things it does so that I can build
> individual pieces of the system as required. More specifically I think I will need
> to modify some functions in newlib and was wondering how that was built. I could
> not see any specific commands that built newlib so I assume that the --with-newlib
> option when building GCC also causes newlib to be built. Can you confirm this? How
> would I just build newlib?
>

There is a command in the first section of the script (where it extracts the source
code) to make a symbolic link to the newlib directory from within the gcc source
directory. This along with the --with-newlib option cause the build to be done with
newlib instead of GNU's run-time library.

It might not be advisable to build newlib separately from gcc. That would exceed my
knowledge of this whole gcc build environment. I don't know. I have done some tweaking
of newlib, but just reran the entire build again, just to be safe. Separating the
building of gcc from newlib seems like a valid thing to want to do. Someone else will
have to answer that one.

Chris

Document / Script for automating cross-compiler build

[Christopher Bahns]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

Hello All,

Attached is a script that is intended to make the building of a
cross-compiler under Windows 95/98/NT and Cygwin 1.1.x as easy and
automated as possible. I don't know if it would be just as useful to
non-Windows people, but I suspect it might be (with some modification
perhaps). But, it is intended for Windows/Cygwin people.

I had a lot of trouble getting compiler builds to work on my SMP
dual-Celeron system running Windows NT 4.0 Workstation. If anyone has
success on an SMP system using Cygwin 1.1.x, please let me know.

The script starts from scratch and assumes that you have nothing except
a computer running Windows NT or 98 (95 should work too, but don't know
about 2000). Unfortunately the only editor you will end up having
available in the Cygwin environment is vi. I prefer Emacs, and have
built and installed XEmacs on my machine, but this is not included in
the attached script. You also will not have the benefit of perl or info.
I really wish Cygnus/RedHat will include at least these three tools in
future releases of its Cygwin environment.

The script also includes some advice on what all you need to get an
embedded program linked and running properly. Although I'm far from an
expert on this, I have gotten my program to run on my M68306-based
device, and I include in the script's comments some of the things I had
to do to get to that point..

Please let me know if this is helpful, or if you have recommendations
for changes/additions, or whether a similar thing already exists for us
unfortunate Windows people and I just could not find it.

The script is currently configured as follows (based on what I needed),
but is designed in a way to make these things easy to change:
    Target: m68k-coff
    Prefix: /gcc-m68k
    binutils-2.10
    gcc-2.95.2
    newlib-1.8.2
I have also done successful builds with the Target set to "m68k-elf".

Chris

[-- Attachment #2: buildgcc.tar.gz --]
[-- Type: application/x-gzip, Size: 8361 bytes --]