RTEMS build problems

[Paul Cadaret]

Joel,
The bootstrap process took a very long time to complete  -- seemed like
well over an hour.
I'm trying to build the 'host-based' version on Solaris 7 now with the
2.59 autoconf & 1.8 automake
in place.  I'm seeing the same error as I saw before.  Here's an extract:

     a - o-optimize/watchdogremove.o
     a - o-optimize/watchdogtickle.o
     a - o-optimize/wkspace.o
     ranlib o-optimize/libscore.a
     Making all in cpu
     Making all in unix
     gcc --pipe -DHAVE_CONFIG_H   -I../../../../../.././posix/lib/include
     -DCPU_SYNC_IO      -Dsolaris2  -O2 -g -Wall  -o o-optimize/cpu.o -c
     ../../../../../../../c/src/../../cpukit/score/cpu/unix/cpu.c
     ../../../../../../../c/src/../../cpukit/score/cpu/unix/cpu.c:62:
     `FD_SETSIZE' undeclared here (not in a function)
     ../../../../../../../c/src/../../cpukit/score/cpu/unix/cpu.c:64:
     parse error before `sync_io_readfds'

This error is caused by the fact that <sys/types.h> needs to see a
definition of '__EXTENTIONS__' which will
cause it to include <sys/select.h> where `FD_SETSIZE' lives.  However, I
am seeing a behavior I dont understand.
Here's an exerpt from the script I created to run 'configure' in the
'build' subdir I createed.

       ${SHELL}  ../configure                                \
             --prefix=$LOCAL                                 \
             --enable-rtemsbsp=""                            \
             CFLAGS_FOR_BUILD=-D__EXTENSIONS__               \
             CXXFLAGS_FOR_BUILD=-D__EXTENSIONS__             \
             #

I specified this definition for the top-level configure, but it doesn't
seem to be trickling down to the lower
level makefile in   build.solaris/c/posix/exec/score/cpu/unix.   If I
look in the Makefile there, I find the following
line:
AM_CPPFLAGS = $(RTEMS_CPPFLAGS) -DCPU_SYNC_IO $(LIBC_DEFINES)

I don't know why the flags that I specified to configure are not showing
up here.

Any ideas?
Am I correct in my understanding that I should be able to build a
'host-based' version on Solaris-7?


Thanks much.
Paul

--------------------------------------------------------------------------------------------

Paul Cadaret wrote:

 >  Joel,
 > Thanks for the tip on running 'bootstrap'.  I must have missed that in
 > the documentation.
 > You mentioned that I need to have autoconf 2.59 and automake 1.8.  The
 > 'README.configure'
 > file says:
 >    To re-generate auto*tool generated files (configure, Makefile.in
 >    etc), autoconf-2.57 and automake-1.7.2 are required.
 >
 > Thanks for the tip on that as well.  That may explain my current
 > Solaris "host-based" build problem.
 > Thanks again.
 > Paul
 >
 > -----------------------------------------------------------
 >
 >> Paul Cadaret wrote:
 >>
 >>>  Webmaster at rtems.com,
 >>> Your web page: http://www.rtems.com/cvs.html   says to use the command
 >>> "cvs -z 9 co -P rtems"  to download the rtems sources.  However, I
 >>> noticed
 >>> that the "configure" script does not get downloaded and I could not
 >>> follow
 >>> the build directions.  I then decided to download the rtems-ss-20030703
 >>> snapshot and there was a substantial difference in the files and a
 >>> 'configure' script was present.
 >>
 >>
 >>
 >> RTEMS CVS does not include automatically generated files.  For example,
 >> it includes configure.ac but not configure and Makefile.am but not
 >> Makefile.in.  When a snapshot tarball is cut, the release script
 >> automatically runs "bootstrap" on the image exported from CVS
 >> and then creates the tarball.  So now you have to run bootstrap
 >> from the top level directory.
 >>
 >> Running bootstrap on the CVS source currently requires autoconf 2.59
 >> and automake 1.8.
 >>
 >> FWIW snapshots were not cut for a while to allow everyone to focus
 >> on the 4.6 branch.  Then the development got moved to newer tools
 >> and there was some period of time where the set of gcc RPMs did
 >> not cover enough targets.  It looks like both 4.6.0 is ready and
 >> it is time for a snapshot.  I test cut one yesterday to verify
 >> that the process worked since some changes to the build infrastructure
 >> impacted the release script.
 >>
 >>
 >