On Fri, 2006-12-08 at 16:25 -0600, Andrew Johnson wrote:
> Hi Ernest,
>
> Ok, I think I've finished integrating your modifications into the build
> system; here's what I've done, and some feedback on your questions.
>
> Ernest L. Williams Jr. wrote:
> >
> > Problems with vxWorks build with new config file structure:
> > (1) Can't build for vxWorks 5.5.X and vxWorks 6.X
>
> Sorry, I'm not letting that Camel's nose in, because someone else will
> want to be able to build for both vxWorks 6.2 and 6.3 - where does this
> stop? See below...
>
> > This is not good. Since our production environment includes both.
> > So, vxWorks-ppc604 gets overwritten by second build of EPICS BASE
> > against a different version of vxWorks. I am sure that other sites that
> > move to vxWorks 6 will experience this.
>
> It should be relatively easy to define a new target architecture
> vxWorks6-ppc604 which inherits its settings from the regular
> vxWorks-ppc604 target but overrides the vxWorks version and directory
> settings. I do not want that architecture to appear in base though.
>
> > I think we should have the config files contain vxWorks major version
> > and BSP name like before. Looks like you allow RTEMS to do this?
>
> No, the numbers after the RTEMS names are all machine architectures
> AFAIK. We do include the BSP name in the RTEMS target architecture
> because when you build an RTEMS IOC you're including the board-specific
> code into the final binary. On vxWorks that is not necessary since we
> don't link the EPICS code with any vxWorks BSP-specific code.
>
> > For example, we are starting to use the altivec support on the MVME5110
> > but the MVME5100 does not have altivec support.
>
> I've added a ppc604_altivec target, which derives from the ppc604_long
> target to permit this. EPICS makes no use of the altivec capabilities,
> but if you're building Base for a system that does do some altivec
> processing the Base code must be built with the appropriate flag set to
> avoid strange problems.
>
> > Another example is using
> > the BSP/target name to discover whether we have a UNIVERSE or Tsi148
> > interface for a DMA driver that we may write. Having, the scheme that
> > we used last time just turns into a bit more compile time and disk
> > space, right?
>
> Anything like that is BSP-specific, and IMHO should appear in the
> vxWorks boot file itself. I have three different implementations with a
> common API that drives the VME DMA engines on the VMEchip2 (MVME16x,
> MVME17x boards), the Universe-2 (MVME2100, 2700, and 5100) and the Tempe
> (MVME6100, 3100).
>
> Alternatively you could create a local alias architecture for your
> different boards that are based on the base targets. If you look at the
> CONFIG.Common.vxWorks-ppc604_long file in the forthcoming R3.14.9-pre2
> release you'll see how simple this is to do: you only have to create the
> relevent CONFIG.Common.vxWorks-xxxx file and tell your build system to
> compile that architecture.
>
> > Running tests in libCom under linux-x86_64:
> > Only the blockingSockTest failed all other passed:
> > =============================================================
> > [williams@dragon O.linux-x86_64]$ ./blockingSockTest
> > 1..1
> >
> > A call to "assert (status == 0)" failed in ../blockingSockTest.cpp line
> > 173.
> > EPICS Release EPICS R3.14.9- $R3-14-9-pre1$ $2006/11/20 21:09:36$.
> > Current time Fri Dec 01 2006 09:41:41.202612000.
> > Please E-mail this message to the author or to [email protected]
> > Calling epicsThreadSuspendSelf()
>
> I'm pretty sure this failed because the test requires that there are no
> CA servers running on the test machine, and that assertion failure comes
> from it being unable to bind to the CA server port.
You are right. I had a softIOC going at the time.
The test now meets with success.
>
> By the way, there's now a much easier way to run all the tests in base -
> you just type 'make -s runtests' and it will run everything and
> summarize the results for you at the end. We only need to see the
> detailed output from a particular test if it fails.
Works great.
>
> As to your patches, almost everything should now be there in the -pre2
> release. I am not setting the -nostdlib flag because it is only used if
> you use gcc/g++ to link, which we don't. I did a diff between two
> builds on Tornado 2.2, with and without that flag, and the results were
> bitwise identical.
>
> - Andrew
- References:
- Next R3.14.9 version: -pre2 or -RC1? Andrew Johnson
- Re: Next R3.14.9 version: -pre2 or -RC1? Ernest L. Williams Jr.
- Re: Next R3.14.9 version: -pre2 or -RC1? Andrew Johnson
- Navigate by Date:
- Prev:
Re: Next R3.14.9 version: -pre2 or -RC1? Ernest L. Williams Jr.
- Next:
Sat. CVS snap built against vxWorks 6.3 Ernest L. Williams Jr.
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Next R3.14.9 version: -pre2 or -RC1? Ernest L. Williams Jr.
- Next:
new osiWireFormat.h and osdWireFormat.h Jeff Hill
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|