top level build problem c instead of "TARGET/c"

Wed May 31 14:14:42 UTC 2000

Thanks.  Comments sprinkled throughout.

Frank Szczerba wrote:
> 
> The Solaris sed does not understand the '\+' construct. The translation
> could be done with sed under Solaris as either:
> > echo c x xyzzy | /bin/sed -e 's%\([^ ]*\)%sparc-rtems/\1%g'
> sparc-rtems/x sparc-rtems/x sparc-rtems/xyzzy
> 
> or (probably more correctly):
> > echo c x xyzzy | /bin/sed -e 's%\([^ ]\{1,\}\)%sparc-rtems/\1%g'
> sparc-rtems/x sparc-rtems/x sparc-rtems/xyzzy

This is what got checked in:

50c50
<  sed -e "s%\([^ ]\+\)%$target_alias/\1%g"`
---
>  sed -e "s%\([a-zA-Z0-9][a-zA-Z0-9]*\)%${target_alias}/\1%g"`

which seems to work.

There is another issue with /bin/sed on Solaris.  It cannot
handle a line as long as appears in some of the Makefile.in's.
I am working on a fix for this as well.

> Also, on the topic of top level build problems, the 'bit' script in
> c_build_scripts-4.5.0-beta3.tgz does not check for success when it builds
> the binutils. If the binutils make fails bit removes the build directory and
> goes on to building gcc, which will of course fail without the binutils. My
> fix was:
> 
> *** orig/bit    Mon May  8 14:43:20 2000
> --- tools/bit   Tue May 16 14:57:41 2000
> ***************
> *** 163,168 ****
> --- 163,169 ----
>         echo "**** SKIPPING BUILD OF BINUTILS  ****"
>       else
>         ${MAKE} all ${MAKE_DOCS} install
> +       check_fatal $?  "**** FAILED **** base build (binutils)"
>       fi
> 
>       cd ..

It was also missing one on the configure above this point.

Thanks.

> This seems to make things better. I also ran into a problem building gcc. At
> some point it wants to do a fix-includes or something similar in the target
> directory, but there are no include files there so it fails. It seems that
> creating an empty $(INSTALL_POINT)/mips64orion-rtems/include directoy fixes
> it. Perhaps this should be done in the bit script?

This is an error in the fixincludes script in gcc.

Ralf spotted a patch for this in the gcc repository.  Basically there
was a piece of non-portable code in the script.

> Last point (I promise): in
> rtems-4.5.0-beta3/c/src/exec/sapi/include/confdefs.h it seems the console.h
> should be included if CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER is defined
> and clockdrv.h included if CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER is
> defined:

These are normally included by bsp.h which is included before
confdefs.h.
This allows the BSP to define its own version of XXX_DRIVER_TABLE_ENTRY.
But this is more proper.

> *** orig/rtems-4.5.0-beta3/c/src/exec/sapi/include/confdefs.h   Fri May  5
> 08:57:14 2000
> --- tools/rtems-4.5.0-beta3/c/src/exec/sapi/include/confdefs.h  Wed May 24
> 16:08:50 2000
> ***************
> *** 216,221 ****
> --- 216,228 ----
>   #include <stubdrv.h>
>   #endif
> 
> + #ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> + #include <console.h>
> + #endif
> + #ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> + #include <clockdrv.h>
> + #endif
> +
>   #ifndef CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
> 
>   #ifdef CONFIGURE_INIT
> 
> Frank Szczerba
> Development Engineer
> Woodward McCoach Inc
> frank at wmi.com
> 
> -----Original Message-----
> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> To: rtems-users at oarcorp.com <rtems-users at oarcorp.com>; Ralf Corsepius
> <corsepiu at faw.uni-ulm.de>
> Date: Thursday, May 25, 2000 3:33 PM
> Subject: top level build problem c instead of "TARGET/c"
> 
> >
> >I have finally reproduced a problem reported multiple times
> >on the list with beta's.  I have tracked down the
> >cause to a specific spot and wanted some feedback on
> >my proposed fix.
> >
> >Does this look familiar to you?
> >
> >make[1]: Leaving directory `/home/joel/b-rtems/tools'
> >Making all in c
> >/bin/bash: c: No such file or directory
> >
> >I got this on Solaris with CONFIG_SHELL settings of
> >/bin/sh, ksh, and an old bash. It is because of this
> >substitution in the top level Makefile:
> >
> >target_subdirs = c
> >...
> >SUBDIRS = doc make tools c
> >
> >The "c" subdirectory should be "sparc-rtems/c" in
> >both cases.  This is what is produced there when this
> >works.  I tracked this down to the following
> >sed in the top level configure.in:
> >
> >TARGET_SUBDIRS=`echo "$target_subdirs" | \
> > sed -e "s%\([^ ]\+\)%$target_alias/\1%g"`
> >
> >Basically sed on some OSes (Solaris in this case is broken).
> >Look at the output of the following:
> >
> >$ echo c | /usr2/tools/bin/sed -e "s%\([^ ]\+\)%sparc-rtems/\1%g"
> >sparc-rtems/c
> >$ echo c | /bin/sed -e "s%\([^ ]\+\)%sparc-rtems/\1%g"
> >c
> >
> >If you tripped this problem and the default sed in your
> >path fails the above test, then I have explained the failure. :)
> >My fix is to avoid sed.  This is what I ended up with:
> >
> >Index: configure.in
> >===================================================================
> >RCS file: /usr1/CVS/rtems/configure.in,v
> >retrieving revision 1.101.2.2
> >diff -u -r1.101.2.2 configure.in
> >--- configure.in 2000/05/08 18:59:18 1.101.2.2
> >+++ configure.in 2000/05/25 19:21:50
> >@@ -45,10 +45,10 @@
> > RTEMS_CONFIG_SUBDIRS(c)
> >
> > if test "$target_alias" != "$host_alias"; then
> >-changequote(,)dnl
> >-TARGET_SUBDIRS=`echo "$target_subdirs" | \
> >- sed -e "s%\([^ ]\+\)%$target_alias/\1%g"`
> >-changequote([,])dnl
> >+TARGET_SUBDIRS=
> >+for t in $target_subdirs ; do
> >+  TARGET_SUBDIRS="${TARGET_SUBDIRS} ${target_alias}/${t}"
> >+done
> > else
> > TARGET_SUBDIRS="$target_subdirs"
> > fi
> >
> >After applying this patch, you will need to run bootstrap.
> >[Or edit the generated configure by hand to make the above
> >substitution]
> >
> >Comments?
> >
> >
> >--
> >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
> >

-- 
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