Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 08 Dec 2006 16:25:25 -0600

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.

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.

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
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System