Part II : Need Help "PPP for 16 bit microcontroller"

Part II : Need Help "PPP for 16 bit microcontroller"

[Syed Raza]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]

Hai 

Thank you very much for reply, below u will find my receiving() &
transmiting() function which may the reason of not getting the whole PPP
packet correctely.

====================================================================
Does this mean that you have two ports connected to the NT-machine and
one to
the Linux-machine (the PPP-link) ?

- yes i am using 3rd SCI channel for debuging and to transmitting the
contents of my buffer, I configure it using a small external RS232/TTL
converter circuit 




Where is your write() outputting now? Why not just change the
default
newlib one:

- my write and read functions(transmit() , receive() respectively) are as
under, i didnt use my receive( ) function as an interrupt 

====
SCI 1 AND 2 INITILIZATION
====
void initio (void)
{ 
SCI_SMR1 = 0x00; 
SCI_BRR1 = 0x0e; 
SCI_SCR1 = 0x30; 
SCI_SSR1 &= 0x84; 
SCI_SMR2 = 0x00; 
SCI_BRR2 = 0x0e; Baud rate 38400 bit/sec
SCI_SCR2 = 0x30; 
SCI_SSR2 &= 0x84; 
}

==================================
Function for receiving the date
===================================
unsigned char receive (void)

{ 
unsigned char c; 
while ((SCI_SSR1 & 0x040) != 0x40) 
{ 
if ((SCI_SSR1 & 0x38) != 0x00) 
{ 
SCI_SSR1 &= 0xC7; 
} 
} 
c = SCI_RDR1; 
SCI_SSR1 &= 0xBF; 
return(c);
} 

void transmit (unsigned char t) 
{ 
while ((SCI_SSR1 & 0x80) != 0x80); 
SCI_TDR1 = t; 
SCI_SSR1 &= 0x7F;
}
===================================================
Function for printing the debuggin info to Hyperterminal
====================================================

void printf(unsigned char *str) 
{ 
while (*str != '\0') 
transmitSCI2(*str++);
}

void transmitSCI2(unsigned char t)
{ 
while ((SCI_SSR2 & 0x80) != 0x80); 
SCI_TDR2 = t; 
SCI_SSR2 &= 0x7F;
}


-- my hitachi board and linux box is using the same baud rate which is
38400 bit/sec 


???????????????????????????????

---------------------- clip
------------------------------------------
int _write(file, ptr, len)
int file;
char *ptr;
int len;
{
int todo;

for (todo = 0; todo < len; todo++) 
{
asm("mov.b #0,r1l\n mov.b %0l,r2l\njsr @@0xc4" : :
"r" (*ptr++) : "r1", "r2");
}
return len;
}
---------------------- clip
------------------------------------------

The problem could not be because of folow control,as i was receiving the
and transmiting the the ASCII characters by using the windows to
Hitachi

looking forward your help 

syed


-------------VTT - Technical Research Centre of
Finland-----------
Syed
Raza                                
 
VTT-Electronics
                      
           
P.O.Box
1100                               
                
FIN-90571 Oulu,
Finland                           


Email: Syed.Raza@vtt.fi    
URL:
www.ele.vtt.fi
Tel: (Res)+358 8 880 4183
Tel: (off)  +358 8  551 2439.
Fax: (off) +358 8 551 2320.
---------------------------------------------------------------------------------



------
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: i686-pc-cygwin to mips64orion-elf cross compiler

[Jeff Domogala]

Folks,

I took Kai's advice and did a make install after the crt0.o issue just to
try and compile and assemble a test file.  I made a simple c file to test
the compiler and assembler:

void test(void)
{
  int a;
  float b = 2.0;

  a=6+2;
  b=a;

  return;
}

I executed the following:

gcc -mcpu=R4650 -g -O0 -EB -c -v test.c

and got the following output from gcc:

Reading specs from /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/specs
gcc version 2.95.2 19991024 (release)

/gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/cpp.exe -lang-c -v -D__GNUC__=2
 -D__GNUC_MINOR__=95 -Dmips -DMIPSEB -DR4000 -D_mips -D_MIPSEB -D_R4000 -D__
mips__-D__MIPSEB__ -D__R4000__ -D___mips__ -D_MIPSEB -D_R4000 -D__mips -D__M
IPSEB -D__R4000 -D___mips -g -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -UMIP
SEL -U_MIPSEL -U__MIPSEL -U__MIPSEL__ -D_MIPSEB -D__MIPSEB -D__MIPSEB__ -DMI
PSEB test.c /cygdrive/c/TEMP/ccyPn21v.i
GNU CPP version 2.95.2 19991024 (release) [AL 1.1, MM 40] BSD Mips
#include "..." search starts here:
#include <...> search starts here:
 /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/include

/gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/../../../../mips64orion-elf/inc
lude
End of search list.
The following default directories have been omitted from the search path:
 /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/../../../../include/g++-3

/gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/../../../../mips64orion-elf/sys
-include
End of omitted list.
 /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/cc1.exe
/cygdrive/c/TEMP/ccyPn21v.i -meb -quiet -dumpbase
test.c -mcpu=R4650 -g -O0 -version -o /cygdrive/c/TEMP/ccWkKnrZ.s
GNU C version 2.95.2 19991024 (release) (mips64orion-elf) compiled by GNU C
version 2.95.2 19991024 (release-2).
 /gcc-mips/mips64orion-elf/bin/as.exe
Assembler messages:
 for reading.open
: No such file or directory

jdomogala@JDOMOGALA2 ~
$

If I do the following sequence of commands:

gcc -mcpu=R4650 -g -O0 -EB -S test.c
as -mcpu=R4650 -g -O0 -EB -o test.o test.s

I get no errors at all.  It appears that gcc is not passing any of the
arguments to as from gcc.  Can anyone help?

Thanks,

Jeff


------
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: i686-pc-cygwin to mips64orion-elf cross compiler

[Kai Ruottu]

Jeff Domogala wrote:
> 
> I took Kai's advice and did a make install after the crt0.o issue just to
> try and compile and assemble a test file.  I made a simple c file to test
> the compiler and assembler:
> gcc -mcpu=R4650 -g -O0 -EB -c -v test.c
> and got the following output from gcc:
> 
> Reading specs from /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
>
>  /gcc-mips/mips64orion-elf/bin/as.exe
> Assembler messages:
>  for reading.open
> : No such file or directory

 Hmmm, did I suggest you to edit the 'specs' file?  Anyway it seems that
there is now something wrong with it. I have used the standard 'WordPad'
with the 'specs'-files under Windoze and haven't yet had any problems.
But knowing how silly tools (= 'clever', those which do things without
asking anything) there can be under Windoze, this perhaps wasn't a very
good advice...

 Anyway the format of the 'specs' file must be maintained. The editor
may not wrap lines, may not add any extra stuff but only what the user
types into it...

 The format of the 'specs' file is simple:

   *spec_name_1:
   the_spec_rules_1

   *spec_name_2:
   the_spec_rules_2

ie. three lines for each spec, and the third being empty. Although the
editor may show the 'the_specs_rules'-line wrapped, it must keep it as
a single line when saving. Whether the lines are ended with only LF
(Unix-like) or with CR/LF (DOS-like) doesn't seem to matter. But the
'clever'-editors (thinking being more intelligent than the user) may
not make a mess from the original file.

Cheers, Kai



------
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: i686-pc-cygwin to mips64orion-elf cross compiler

[Jeff Domogala]

For some strange reason, the last line (blank) of the specs file was the
problem.  Once that was fixed, gcc worked.  My test file compiled and
assembled.  Thanks for the help!

Jeff

-----Original Message-----
From: crossgcc-owner@sources.redhat.com
[ mailto:crossgcc-owner@sources.redhat.com]On Behalf Of Kai Ruottu
Sent: Monday, September 25, 2000 12:26 PM
To: Jeff Domogala
Cc: crossgcc@sources.redhat.com
Subject: Re: i686-pc-cygwin to mips64orion-elf cross compiler


Jeff Domogala wrote:
>
> I took Kai's advice and did a make install after the crt0.o issue just to
> try and compile and assemble a test file.  I made a simple c file to test
> the compiler and assembler:
> gcc -mcpu=R4650 -g -O0 -EB -c -v test.c
> and got the following output from gcc:
>
> Reading specs from /gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
>
>  /gcc-mips/mips64orion-elf/bin/as.exe
> Assembler messages:
>  for reading.open
> : No such file or directory

 Hmmm, did I suggest you to edit the 'specs' file?  Anyway it seems that
there is now something wrong with it. I have used the standard 'WordPad'
with the 'specs'-files under Windoze and haven't yet had any problems.
But knowing how silly tools (= 'clever', those which do things without
asking anything) there can be under Windoze, this perhaps wasn't a very
good advice...

 Anyway the format of the 'specs' file must be maintained. The editor
may not wrap lines, may not add any extra stuff but only what the user
types into it...

 The format of the 'specs' file is simple:

   *spec_name_1:
   the_spec_rules_1

   *spec_name_2:
   the_spec_rules_2

ie. three lines for each spec, and the third being empty. Although the
editor may show the 'the_specs_rules'-line wrapped, it must keep it as
a single line when saving. Whether the lines are ended with only LF
(Unix-like) or with CR/LF (DOS-like) doesn't seem to matter. But the
'clever'-editors (thinking being more intelligent than the user) may
not make a mess from the original file.

Cheers, Kai



------
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: i686-pc-cygwin to mips64orion-elf cross compiler

[Rob Taylor]

>  /gcc-mips/mips64orion-elf/bin/as.exe
> Assembler messages:
>  for reading.open
> : No such file or directory

it's not parsing your specs file correctly. I got this problem when my make
created my specs file with CR/LF's ratehr than LF's (as you can see, it's not
passing in any arguments to gas, in my problem this was because it was starting
to read asm-spec 2 bytes too early and reading \r\n rather than the asm spec.
must be something to do with calculating the length of the various strings in
spec)

if editing the file made it start working, could this be because you saved out
with unix line-endings?

I have to wonder where the bug is that causes this.. should gcc be able to read
a specs file that has CR/LFs or should it be considered a bug in the build
process?
any gcc maintainers here to comment? ;)

Rob Taylor


------
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: i686-pc-cygwin to mips64orion-elf cross compiler

[Kai Ruottu]

Jeff Domogala wrote:
> 
> I've been attempting to build a i686-pc-cygwin to mips64orion-elf cross
> compiler with cygwin 1.1.4 installed.  I have run into a series of issues
> along the way, and I am still stuck at this point.
> 
> I used binutils-2.10 and gcc-2.95.2 this time and use the same configuration
> options (after wiping out the previous attempt of course).  I built binutils
> without a hitch and the build of gcc did not require the header file
> modification.  But, this time I got the following while building gcc:
> make[2]: Entering directory
> `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
> make[2]: *** No targets specified and no makefile found.  Stop.
> 
> Here is the contents of config.log from
> `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty':
>
> configure:1749: checking whether the C compiler
> (/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.
> 2/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -g -O2 ) works

 The words 'C compiler' are wrong here, it really means 'toolset' or something
more bigger than just the compiler, ie. the assembler, linker, startup-routine
(crt0.o), C-library (libc.a), linker script etc. are checked before trying
libiberty.

 So your GCC compiler (in the 'gcc' subdir)  most probably works now, you can
compile a C-file into assembly with it (-S), use the target 'as' to produce an
object file, '.o' (-c) etc. But you cannot yet link without the startup-routine
(crt0.o) and without proper C-libraries (lib*.a)...

> configure:1765:
> /cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
> /gcc/ -B/gcc-mips/mips64orion-elf/bin/ -o conftest -g -O2   conftest.c  1>&5
> /gcc-mips/mips64orion-elf/bin/ld: cannot open crt0.o: No such file or
> directory
> 
> It looks like to me that I need crt0.o for ld to work correctly.  So, how do
> I create this file and does it have to be made for the host or the target?

 The startup-routine belongs into your C-libraries and is a part of the Cygnus
newlib. The newlib includes some startups, either in the libgloss/mips (or in the
newlib/libc/sys/mips) for the supported target boards.

 I refer to my another message about the 'Makefile.in' fixes, whether to build
newlib at the same time with GCC, or to just pre-install the newlib ('target')
headers, as the GCC-manual suggests, then build only GCC using 'make all-gcc'
or something, install GCC and then build newlib separately, install it, fix
the 'specs' for GCC (see later) so that one can link and produce a simple
"Hello World" executable with GCC + newlib etc. And when everything seems to
work, to let the 'GCC build' try the same before building libiberty & Co...

 Doing things one at a time and trying to understand what the separate tools
really do while 'compiling', e.g. that the 'xgcc + cpp + cc1'-chain produces
only assembly for 'as'. Trying the '-v' with the native GCC tells quite a lot
about the 'compiling phases'.

 In order to produce GCC for the target, one needs only the target headers and
the binutils for the target. Nothing more. For producing executables for the
target one needs the target libs, including the startup-routine.

 So you will need the 'crt0.o' for the 'target' now or later. The first thing to
understand is that you really need a real 'target'... While a 'mips-linux-gnu'
involves a defined startup for Linux/MIPS, known system calls for Linux in its
C-library etc., your 'mips64orion-elf' says only the CPU-type and the object
format, not anything about the I/O-arrangement or 'opsys' in your target board.
There aren't any 'defaults' for these things in the GCC config files...

 Ok, the 'specs'-file has the default options given to the linker, here is a
clip from my 'specs' for 'mips64orion-elf' :

--------------- clip ------------------------
*cc1plus:


*endfile:
crtend%O%s

*link:
%{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{bestGnum} %{shared} %{non_shared} %(linker_endian_spec) -T pmon.ld%s

*lib:
-lc -lpmon -lc

*libgcc:
-lgcc

*startfile:
crtbegin%O%s crt0%O%s

*switches_need_spaces:

--------------- clip ------------------------

 The freely available 'PMON'-monitor on the target board is my default
for the 'opsys', so its linker script 'pmon.ld' and its glue library
(for the low-level-I/O like 'read()', 'write()',...) are defined here.

 Ok, you will have the 'crt0.o' in 'gcc-mips/mips64orion-elf/lib' after
building and installing first GCC, then newlib, and GCC will find it
automatically (because already installed), but if you try the GCC and
newlib at the same time, you haven't the probably needed
  -B/gcc-mips/mips64orion-elf/lib
in the options given to 'xgcc', so the linker doesn't find it because
of the new 'relative search paths' using the:
  $prefix/lib/gcc-lib/$target/$version/../../../../$target/lib
instead of the straight path:
   $prefix/$target/lib

> It is not addresses in the crossgcc FAQ.

 Did you RTFM at all before looking the FAQ ?  "Installation/Cross-Compiler"
in the GCC-manual (> 500 pages) really tells about the 'crt0.o', C-library
for the target etc.

 The most common problem seems to be that people no more ask questions like
"I have GCC but no manual for it, where the hell it is ?". I haven't seen this
'obvious' question asked for a while although all Linux distributions seem to
miss the manual, Cygwin ?, Mingw ? ... The GCC-manual not belonging to a GCC-
distribution ?  Bullshit... (Perhaps the 'gcc.info' is included, but it should
be history...)

 I prefer PDF, so e.g. the RedHat/Cygnus 'Embedded Development Toolkit' (EDK)
at: ftp://ftp.redhat.com/pub/redhat/edk , and the PDF & HTML-manuals with it
(although for 'gcc-2.9-99r1p1') can be suggested, until one builds his/hers
own ones from the GCC-sources using Tex, Ghostscript, texi2html etc.

 Someone described the GCC-manual production process on this list some months
ago... I would consider this skill just as important as producing the toolset
binaries. After the toolset build one should have the binaries and ALSO the
docs for it... The Cross-GCC FAQ addressing the docs-building at all ?

 Hmmm, if I continue critizing the FAQ, not contributing anything to it (how
I could when not agreeing with it?), soon I must write one myself (from all
the answers I have written to this list...). The big problem is that I have
my own NIH-like opinions about the things, not always agreeing with the FAQ... 

> One last thing...  I was assuming that I did not need to build a native
> toolchain with the non-cygnus tree before I built the cross compiler.  Is
> this a correct assumption?  I read the entire crossgcc FAQ and did not see
> an answer to this question.

 Of course you don't need it...
 
 Cheers, Kai



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

i686-pc-cygwin to mips64orion-elf cross compiler

[Jeff Domogala]

I've been attempting to build a i686-pc-cygwin to mips64orion-elf cross
compiler with cygwin 1.1.4 installed.  I have run into a series of issues
along the way, and I am still stuck at this point.

I originally attempted to build the cross compiler using the following
cygwin tree components from 1.1.4:
  binutils-20000722-1
  gcc-2.95.2-2.

The parameters I used with configure for binutils and gcc are:
--host=i686-pc-cygwin --target=mips64orion-elf --prefix=/gcc-mips --with
gnu-ld --with-gnu-as -v

I built binutils with: make all install.  There were no errors.
I then put $prefix/bin in $PATH so gcc could find the target specific
utilities.

I then built gcc with: make all LANGUAGES="C C++" install.

The first problem I had was a prototype conflict for make_temp_file():

gcc -c -DCROSS_COMPILE -DIN_GCC     -g -O2  -DHAVE_CONFIG_H    -I. -I../../g
cc-2.95.2-2/gcc -I../../gcc-2.95.2-2/gcc/config -I../../gcc-2.95.2-2/gcc/../
include../../gcc-2.95.2-2/gcc/config/mips/mips.c
../../gcc-2.95.2-2/gcc/config/mips/mips.c:96: conflicting types for
`make_temp_file'
../../gcc-2.95.2-2/gcc/../include/libiberty.h:69: previous declaration of
`make_temp_file'
make[1]: *** [mips.o] Error 1
make[1]: Leaving directory `/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc'
make: *** [all-gcc] Error 2

I commented out the offending prototype in
gcc-2.95.2-2/gcc/../include/libiberty.h:69 since its return type was
different than the rest of the mips routines.

The second make gcc make attempt produced the following error:

Testing libgcc1.  Ignore linker warning messages.
/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95
.2-2/gcc/ -B/gcc-mips-cygwin/mips64orion-elf/bin/ -I/gcc-mips-cygwin/mips64o
rion-elf/include -DCROSS_COMPILE -DIN_GCC     -g -O2 -I./include
libgcc1-test.o -o libg
cc1-test \
  -nostartfiles -nostdlib
`/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.9
5.2-2/gcc/ -B/gcc-mips-cygwin/mips64orion-elf/bin/ -I/gcc-mips-cygwin/mips64
orion-elf/include --print-libgcc-file-name`
collect2: ld terminated with signal 11 [Segmentation fault]
      0 [main] ld 8214 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  16956 [main] ld 8214 stackdump: Dumping stack trace to ld.exe.stackdump
make[1]: *** [libgcc1-test] Error 1
make[1]: Leaving directory `/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc'
make: *** [all-gcc] Error 2

Here's the contents of the stack trace file:
Exception: STATUS_ACCESS_VIOLATION at eip=0045B901
eax=00000002 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000001
ebp=0259F800 esp=0259FAB8
program=D:\cygwin\gcc-mips-cygwin\mips64orion-elf\bin\ld.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0259F800  0045B901  (00000000, 00000000, 00000000, 00000000)
0259FB20  0045B901  (0A060588, 004914AC, 0A060CD8, 0A061D30)
0259FC80  0043E508  (0A060588, 004914AC, 0259FCE0, 00000000)
0259FCA0  0043BDAA  (0A060588, 004914AC, 0259FCDC, 6102285E)
0259FCE0  004135A3  (0A052B00, 0259FD28, 0259FD30, 00413FFA)
0259FD30  00414004  (0A052A60, 00000000, 0259FD70, 00417ACE)
0259FD70  00417AE8  (0A0529D8, 0A051CA8, 00000000, 6103EF38)
0259FDA0  0041ADF4  (00000008, 0A0529D8, 0A051CA8, 61002241)
0259FF10  61002272  (FFFFFFFF, 00000000, 77F763D3, 77F763DB)
0259FF70  61002805  (0041A758, 00000000, 0259FFA0, 0048C89D)
0259FF80  61002843  (00000000, 00000000, 00000000, 00000000)
0259FFA0  0048C89D  (0041A758, 81491460, 81491300, 77F1B9E7)
0259FFC0  00401035  (00000000, 00000000, 7FFDF000, 7FFDF000)
0259FFF0  77F1B9EA  (00401000, 00000000, 000000B0, 00000100)
End of stack trace

I gave up at this point with this setup but would like some direction, if
there is somewhere I can go with this.  It looks to me like the linker is
hosed for mips.

I decided to attempt to build a cross compiler from a non-cygnus tree.

I used binutils-2.10 and gcc-2.95.2 this time and use the same configuration
options (after wiping out the previous attempt of course).  I built binutils
without a hitch and the build of gcc did not require the header file
modification.  But, this time I got the following while building gcc:

make[2]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/lib
io'
cd ../libiberty ; make "SHELL=/bin/sh" "INSTALL=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c" "INSTALL_DATA=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c -m 644" "INSTALL_PROGRAM=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c " "prefix=/gcc-mips"
"exec_prefix=/gcc-mips" "tooldir=/gcc-mips/mips64orion-elf"
"gxx_include_dir=/gcc-mips/include/g++-3"
"libsubdir=/gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2"
"gcc_version=2.95.2"
"gcc_version_trigger=/cygdrive/d/gnu/gcc-2.95.2/gcc/version.c"
"AR=mips64orion-elf-ar" "AR_FLAGS=rc"
"CC=/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.
95.2/gcc/ -B/gcc-mips/mips64orion-elf/bin/"
"CXX=/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2
.95.2/gcc/ -B/gcc-mips/mips64orion-elf/bin/" "CFLAGS=-g -O2"
"CXXFLAGS=-g -O2" "NM=mips64orion-elf-nm" "RANLIB=mips64orion-elf-ranlib"
"LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "LOADLIBES="
"LDFLAGS="
"MAKEINFO=/cygdrive/d/gnu/build-gcc-2.95.2/texinfo/makeinfo/makeinfo "
"SHLIB=libstdc++.so.2.10.0" "SHCURSES=" "RUNTESTFLAGS="
make[2]: Entering directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
make[1]: *** [../libiberty/libiberty.a] Error 2
make[1]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libstdc++'
make: *** [all-target-libstdc++] Error 2

Here is the contents of config.log from
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty':
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:591: checking host system type
configure:614: checking build system type
configure:640: checking for mips64orion-elf-ar
configure:672: checking for mips64orion-elf-ranlib
configure:749: checking for gcc
configure:828: checking whether we are using GNU C
configure:837:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E conftest.c
configure:852: checking whether
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ accepts -g
configure:881: checking for POSIXized ISC
configure:919: checking for a BSD compatible install
configure:980: checking how to run the C preprocessor
configure:1001:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/file.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/param.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for stdlib.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for string.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for unistd.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for strings.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/time.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/resource.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1100: checking for sys/wait.h that is POSIX.1 compatible
configure:1121:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -c -g -O2  conftest.c 1>&5
configure:1749: checking whether the C compiler
(/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.
2/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -g -O2 ) works
configure:1765:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -o conftest -g -O2   conftest.c  1>&5
/gcc-mips/mips64orion-elf/bin/ld: cannot open crt0.o: No such file or
directory
collect2: ld returned 1 exit status
configure: failed program was:

#line 1760 "configure"
#include "confdefs.h"

main(){return(0);}

It looks like to me that I need crt0.o for ld to work correctly.  So, how do
I create this file and does it have to be made for the host or the target?
It is not addresses in the crossgcc FAQ.

One last thing...  I was assuming that I did not need to build a native
toolchain with the non-cygnus tree before I built the cross compiler.  Is
this a correct assumption?  I read the entire crossgcc FAQ and did not see
an answer to this question.

Any help would be greatly appreciated.

Thanks,

Jeff Domogala


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