Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Sun, 10 Dec 2006 21:27:15 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System