rtems-ss-20030128 problem

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Mon, 2003-02-03 um 17.48 schrieb Joel Sherrill:
> > Francesco Poletti wrote:
> > >

> > -TMPINSTALL_FILES += $(PROJECT_INCLUDE)
> > -TMPINSTALL_FILES += $(include_HEADERS:%.h=$(PROJECT_INCLUDE)/%.h)
> > +PREINSTALL_FILES  = $(PROJECT_INCLUDE)
> > +PREINSTALL_FILES += $(include_HEADERS:%.h=$(PROJECT_INCLUDE)/%.h)
> >
> >  TMPINSTALL_FILES += $(PROJECT_RELEASE)/lib/shmdr$(LIB_VARIANT).rel
> >
> > Ralf, does this look right to you?
> No, it doesn't. Your change changes pre-installation of these files from
> "installation-on-the-fly" to "forced pre-installation".

OK.  I guess I am not seeing the right approach then.
 
> >   The .h files need to be installed
> > before the code is compiled and the .rel afterwards.
> That's exactly the point needing to be investigated.
> 
> Therefore: Which part of RTEMS code makes you say this? I don't see it.

The build failure is this:

-c ../../../../../../current/c/src/lib/libbsp/shmdr/getlq.c
../../../../../../current/c/src/lib/libbsp/shmdr/getlq.c:24:24:
shm_driver.h: No such file or directory

which lead me to believe that the .h needed to be installed before
the code was compiled.  Looking at the all-local rule, I saw

all-local: $(ARCH) $(PREINSTALL_FILES) $(PGM) $(TMPINSTALL_FILES)

So I assumed that they needed to be before PGM not after.  So I
move the .h's to PREINSTALL_FILES and left .rel in TMPINSTALL_FILES.


> >   I think this is
> > right.
> It shouldn't do any harm.

If it isn't 100% correct, what is the 100% canonically correct way to
do it?  I know I want to do things the right way.

>
> > > checking whether to build rtems++... no
> > > configure: error: conditional "am__fastdepCXX" was never defined.
> > > Usually this means the macro was only invoked conditionally.
> > > configure: error: /bin/sh '../../../../../../rtems-ss-20030128/c/src/tests/libtests/configure' failed for libtests
> > > configure: error: /bin/sh '../../../../../rtems-ss-20030128/c/src/tests/configure' failed for tests
> > > gmake[2]: *** [arm_bare_bsp] Error 1
> > >
> > > May anyone help me?
> To be investigated. I recall this kind of bug being present in an older
> snapshot, but I thought I had fixed it.
 
> > I have see this but not been able to reproduce it enough to track it
> > down.
> > My 1st suspicion was that for some reason --enable-cxx must be set when
> > you have multiprocessing enabled.  But I just tried that combination and
> > can't reproduce that.  Any thoughts Ralf?
> I need to look into the source-code. I could have missed something, it
> could be a packaging bug, could be problems with autom4te.caches.

I didn't see this on the overnight build but I didn't have tests enabled
for the "vary all the configuratin settings" sweep.  Let me turn tests
on and re-churn.  Maybe it will show up a helpful pattern.

> Ralf

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