EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: mrkSoftTest doesn't compile
From: Ralph Lange <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Janet Anderson <[email protected]>, EPICS Core Talk <[email protected]>
Date: Thu, 17 Nov 2005 16:34:19 +0100
That's how I would expect things to work, but it's not working correctly.

Again - the generic location is determined from declarations in BASE/configure/CONFIG_BASE_VERSION, which are setting the version info for a 3.14.7 - even though that Base really is the future 3.14.8. Again my suggestion: BASE/configure/CONFIG_BASE_VERSION should be updated immediately *after* a shipping out a release to point to the next release number. Then the generic path would be non-existing while I'm compiling and testing a new base.

My mrkSoftTest's configure/RELEASE file contains:

#RELEASE Location of external products
EPICS_BASE=/home/unix/lange/work/epics/APS/epics/base/3-14-X
VX_STATS=/home/unix/lange/work/epics/APS/epics/vxStats
TEMPLATE_TOP=$(EPICS_BASE)/templates/makeBaseApp/top
MSI=/home/controls/epics/extensions/bin/$(EPICS_HOST_ARCH)/msi$(HOSTEXE)
EPICS_EXTENSIONS=/home/unix/lange/work/epics/APS/epics/extensions

That's all that is in there - the generic location is not mentioned at all, the local build location is first.

Nevertheless, the configuration files in EPICS Base are setting the generic location as an argument to the -L linker option. This is not the desired behaviour and should be fixed. In Base, not in mrkSoftTest.

Ralph


Andrew Johnson wrote:

Hi Ralph,

Ralph Lange wrote:


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?


There is no problem having more than one path defined (it will just look through them one after the other until it finds the .so file), but you must ensure that it will never find a different version of the libraries at runtime than it saw at compile time, as I think I wrote yesterday - your 'final install' path should be pointing to an empty or non-existent directory until that version of base has been installed. You might also want to adjust the search order so it looks in the local build first by changing the order of the items in your mrkSoftTest's configure/RELEASE file; shared library searches should occur in the same order as the lines in that file.

- Andrew


References:
mrkSoftTest doesn't compile Ralph Lange
Re: mrkSoftTest doesn't compile Ralph Lange
Re: mrkSoftTest doesn't compile Andrew Johnson

Navigate by Date:
Prev: Re: mrkSoftTest doesn't compile Andrew Johnson
Next: [Fwd: RE: Patches to support linux-arm for EPICS base] Andrew Johnson
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: mrkSoftTest doesn't compile Andrew Johnson
Next: Re: mrkSoftTest doesn't compile Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·