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: Build system problem
From: Ralph Lange <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 17 Nov 2005 11:04:50 +0100
Right.

But:
The generic path definition is built from the definitions in configure/CONFIG_BASE_VERSION (see configure/os/CONFIG_SITE.Common.hpux-parisc), and these still have the old numbers. Should the definitions in CONFIG_BASE_VERSION be changed in the CVS repository immediately *after* a release instead of *before* releasing? For now, I get the correct generic path as soon as 3.14.8 is released, as Janet is changing the numbers as part of creating the release.

So we do have an agreement that the -L option should always point to the loacl build tree. Good. I don't feel comfortable enough (yet) with the new configure files to apply a fix. I guess that something has to be changed with the definition of SHRLIB_DEPLIB_DIRS in configure/os/CONFIG.Common.UnixCommon, but I'm not sure what exactly is wrong there.

Ralph


Andrew Johnson wrote:

Ralph Lange wrote:

The two -Wl options (compiled-in locations for shared libraries) are correct: One location is the generic location, where the EPICS Base will be installed. The other is the local directory, i.e. the location of the Base that I'm currently linking against. This makes sure that the libraries are found on the development machine as well as on the runtime system (where the Base will be installed at the generic location).


Shouldn't your 'generic' path be pointing to an empty or non-existent directory though when you're compiling? You should change that path to /opt/epics/R3.14.8/support/base/3-14-8-0 or similar, so it will never try to link against old libraries. The -L option *should* be pointing to your local build tree since that gets used at compile time, but at runtime you also want it to search the install location.

- Andrew


References:
mrkSoftTest doesn't compile Ralph Lange
Re: mrkSoftTest doesn't compile Marty Kraimer
Build system problem (was: mrkSoftTest doesn't compile) Ralph Lange
Re: Build system problem Andrew Johnson

Navigate by Date:
Prev: RE: R3.14.8 Status/logClient patch Jeff Hill
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 
Navigate by Thread:
Prev: Re: Build system problem 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 ·