Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 17 Nov 2005 16:46:42 +0100

Hi Janet,

Janet Anderson wrote:

Ralph Lange wrote:

Hi Janet,

I don't have any system with a gcc 4 running - it's all gcc 3.

I do *NOT* have 3.14.7 in my mrkSoftTest/configure/RELEASE.

Why does 3.14.7 base appear in the -L option of the link lines?

I don't know. That's why I'm asking.
It seems that things within the 3.14 build system set it that way.

I intentionally create 2 -Wl options, because here the location of

Base differs between development and production systems. To be able

to run the exe on both worlds, I'm compiling both paths into the

binaries: the local - for development, and the generic - for the

production systems.

Is it illegal to use two compiled-in paths? From first glance I

wouldn't see why.

Does the build system rely on just one path being defined? If so: Is

that limitation justified?

When you say system do you mean subnet. If not how do you switch the .exe
between systems.

I mean system. And I don't switch exes.

There's one development machine within our office network.

There are multiple production machines in different subnets, including

our office network.

I'm compiling on the development machine, then distribute Base's bin,

lib and include folders to all production machines, near and far.

The location on all production machines is the generic one, on the

development machine I have to use my development location, as the

generic location does not exist. I want the exes to run in all places.

No, its not illegal and the build system does not rely on only 1 path.

Still the build system seems to create the -L location from what's

defined for the compiled-in paths, obviously taking the first path

that's mentioned there.

Clueless,
Ralph

Janet Anderson wrote:

Hi Ralph,

Is it possible that your R3.14.7 EPICS base on linux was built with

gcc version 3 and you are now building with gcc version 4?

Why do you have R3.14.7 in your mrkSoftTest/configure/RELEASE file?

You shouldn't have 2 -Wl options for EPICS base.

Janet

Ralph Lange wrote:

Marty,

mrkSoftTest doesn't compile aymore (neither on HP nor on Linux):

aCC -o access

-L/opt/epics/R3.14.7/base/3-14-7-0/lib/hpux-parisc/ -AA -mt

-Wl,+b/home/unix/lange/work/epics/APS/epics/base/3-14-X/lib/hpux-parisc:/home/unix/lange/work/epics/APS/epics/extensions/lib/hpux-parisc:/opt/epics/R3.14.7/base/3-14-7-0/lib/hpux-parisc,+s

access_registerRecordDeviceDriver.o asinittest.o asTest.o

asTrapWriteTest.o accessMain.o -lrecIoc -lsoftDevIoc -liocsh

-lmiscIoc -lrsrvIoc -ldbtoolsIoc -lasIoc -ldbIoc -lregistryIoc

-ldbStaticIoc -lca -lCom

/usr/ccs/bin/ld: Unsatisfied symbols:

 pvar_int_dbRecordsOnceOnly (first referenced in

access_registerRecordDeviceDriver.o) (data)

On Linux:

/usr/bin/g++ -o common

-L/opt/epics/R3.14.7/support/base/3-14-7-0/lib/linux-x86/

-Wl,-rpath,/opt/epics/R3.14.7/support/base/3-14-7-0/lib/linux-x86

-Wl,-rpath,/home/unix/lange/work/epics/APS/epics/base/3-14-X/lib/linux-x86

-Wl,-rpath,/home/unix/lange/work/epics/APS/epics/extensions/lib/linux-x86

devAiAsyn.o common_registerRecordDeviceDriver.o commonMain.o

-ltestDevIoc -lrecIoc -lsoftDevIoc -liocsh -lmiscIoc -lrsrvIoc

-ldbtoolsIoc -lasIoc -ldbIoc -lregistryIoc -ldbStaticIoc -lca -lCom

common_registerRecordDeviceDriver.o(.text+0x4a1): In function

`__static_initialization_and_destruction_0':

/net/unix/mnt/csr-home/lange/work/epics/APS/epics/mrkSoftTest/common/src/O.linux-x86/common_registerRecordDeviceDriver.cpp:264:

undefined reference to `pvar_int_dbRecordsOnceOnly'

I don't see any changes in mrkSoftTest, though. Strange. I'm pretty

sure you know faster than me what's wrong ...

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System