Problems Building RTEMS on CYGWIN

[MARK_FARNAN at HP-Australia-om4.om.hp.com (MARK_FARNAN at HP-Australia-om4.om.hp.com)]

Thenks for the response, however I have actually fixed the problem and it was 
MAKE

Upgradeing to MAKE 3.77 fixes it completley.


I have no completley configured and installed RTEMS, however there are 3 other 
bugs, which I have investigated and fixed.
I can send you extensive detail, and code snippets if required for where the 
problemn is in each script, and what the fix might be.

Breifly.

1.  CONFIGURE hangs or says 'unabel to generate executable' on NT when checking 
for the TARGET gcc compiler.

Reason:  To test if the target is a cross-compiler, the script tries to 'RUN' 
the output of CONFTEST.c.  The output of the SH-RTEMS-GCC compile is 
CONFTEST.EXE which will run on an NT box, however breaks with invalid 
instructions, or hangs, or crashes the complete shell.

FIX:  I Fixed it by removing the IF / ELSE / FI section in the CONFIGURE script 
for checking if the target is a cross compiler, and forced the 
is_cross_compiler (or whaterver the Variable is) to TRUE.
A better fix will be to edit the script to not run it, but maybe compare the 
target and host, etc.



2. NAME_MAX not found in sys/direent, which is used by reedirect.c  (I think, 
will find it exaclty if you want)
 It import <limits.h>  which does contain NAME_MAX,....in Theory, however it 
dosn't seem to get the correct <limits.h>  and the NAME_MAX variable is not 
defined.

FIX: Fixed it temporarily by replacing NAME_MAX with absolutie value of 14 from 
the <limits.h>.  I believe the problem is that it is not picking up the correct 
<limits.h> file somehow.  (there seem to be about 7 different ones scattered 
around the place)

QUESTION:  How do we confirm WHICH file is being included (i.e which limits.h) 
or how do I print out the Include search path 
?



3. Install dosn't work, because it bombs with being unable to mkdir in the 
install point.
 Traced it back to TARGET.CFG  (forget the directory)  and specificaly the 
PREFIX value   
 (mine was PREFIX=/gcc-sh-rtems  )  it appears that it has a CR/LF appended to 
this line.  which was causing a CR to be  in the variable.  It is ONLY this 
line in ther TARGET.CFG file with the problem, which is weird.  

FIX:   edit and re-save TARGET.CFG in UNIX format (or do a DOS2UNIX on the 
file).

QUESTION:  Any Idea why the CR/LF is put on the PREFIX line ???????


Anyway.

 Installing MAKE 3.77
 After Configure do
 Edit direent.h   change NAME_MAX to 14
 DOS2UNIX TARGET.CFG

With these 3 little mod's, RTEMS 4.0.0 compiled and installs completley.

Also, your documentation for the WIN32 hosting has some typo's in it, including 
a big error in the CONFIGURE parameters for the EGCS build.

Also, CYGWIN B20.1  PATCH seems to work fine, you do not need to do a DOS2UNIX 
on the patched files.

    
Lastley, when I start work on actually making it work on my platform next week, 
If you want, I will work out better fixes for these problems, unless you gents 
know about them already.


Mark Farnan
NT Resolution Engineer
Mission Critical Support Center
Hewlett Packard Australia
+61-3-9272-2875 


> -----Original Message-----
> From: Non-HP-joel /HP-Australia,mimegw1/dd.HPMEXT1=joel at oarcorp.com 
> Sent: Wednesday, 12 May 1999 0:00
> To: Non-HP-mfarnan
> /HP-Australia,mimegw1/dd.HPMEXT1=mfarnan at bigpond.net.au
> Cc: Non-HP-joel /HP-Australia,mimegw1/dd.HPMEXT1=joel at oarcorp.com;
> Non-HP-rtems-list
> /HP-Australia,mimegw1/dd.HPMEXT1=rtems-list at oarcorp.com
> Subject: RE: Problems Building RTEMS on CYGWIN
> 
> 
> 
> On Tue, 11 May 1999, Mark Farnan wrote:
> 
> > I have traced the problem to MAKE.  For some reason the 
> section of the
> > Makefile that installs the build-tools, won't do it.  It is 
> telling me there
> > is no rule to build them, when it seems the rule is there 
> in the file.
> > 
> > If I do the 'install'  for install-if-change and the other 
> tools manually,
> > the rest of the compilation works fine.
> > 
> > Any more Ideas ??
> 
> Could you post the output of this?
> 
> What install program is actually being used?  We have seen 
> recent cases
> where install does not install multiple programs on a single 
> invocation.
> In this case, adding a for loop around the install invocation 
> fixes it.
> The loop is something like this:
> 
> > all:    $(ARCH) $(DESTDIR) $(SRCS) $(PGMS)
> >         @for f in $(PGMS) xxx; \
> >         do if [ $$f != xxx ] ; then \
> >             @INSTALL@ $(INSTBINFLAGS) $$f $(DESTDIR); \
> >         fi ; done ;
> 
> This showed up on Solaris but the symptoms sound somewhat similar.
> 
> --joel
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 
>