Experimental Physics and
Industrial Control System

John Dobbins <[email protected]> · Mon, 8 Mar 2010 12:02:40 -0500

Mark,

Yes the files are on a remote server. I can try locating them locally.

John
________________________________________
From: Mark Rivers [[email protected]]
Sent: Monday, March 08, 2010 11:57 AM
To: John Dobbins; EPICS Tech-Talk
Subject: RE: Building EPICS on windows (reprise)

John,

I don't know what the problem is, but I think it is almost certainly not
related to that patch problem.  That problem caused applications to die
when they started, both IOC applications and some tools in base.

Are your files local or on a server?  Could you be having network
problems that cause the linker not to be able to find some libraries?
Just a guess ...

Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John Dobbins
Sent: Monday, March 08, 2010 10:43 AM
To: EPICS Tech-Talk
Subject: Building EPICS on windows (reprise)

Last August I experienced trouble building EPICS R3.1.4.10 on Win32.

See thread:

http://www.aps.anl.gov/epics/tech-talk/2009/msg01132.php

It turned out that I was building on a Xeon 3040 dual core machine and I
had to apply a patch described in the R3.14.10 "Known Problems"
documentation.

"IOCs or other EPICS programs running on a Win32 system with multiple
CPUs may die at startup. This problem can also cause some of the EPICS
build tools to die and for the build to fail (any of these programs
could cause this: aitGen, antelope, dbToMenuH, dbToRecordtypeH, e_flex,
genApps, makeBpt). This patch applied to the
base/src/libCom/osi/os/WIN32/osdTime.cpp file solves an issue with time
provider registration on Windows."

Everything was fine until last week when this Xeon based PC died. Our
computer group replaced it with a nominally identical spare - but it
turns out that this spare has "Pentium Dual CPU", E2180  instead of the
Xeon.

On this replacement I cannot get EPICS to build with or without the
patch. Base might build, but then as I tried to build various products,
e.g. asyn or autosave, I would eventually run into an "unresolved
symbols" error where there shouldn't be one. This is the same type of
error I originally came across back in August< seem to be independent of
compiler choice - Microsoft, MinGW

Just for fun I also tried R3.14.11 on the "Pentium Dual CPU" E2180
without success.

At the moment I am trying to replicate the build on another Xeon machine
but I am befuddled by this whole issue. Normally I wouldn't think twice
about the particular CPU model I am using.

Any advice?

John Dobbins

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System