[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Mon, 03 Feb 2003 12:19:36 -0600
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: rtems-ss-20030128 problem
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:
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: *** [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.
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