Hi Yong,
Ø
So, my questions: do we really need the following 3 lines in asyn/configure/RELEASE?
Ø
SUPPORT=/corvette/home/epics/devel
Ø
IPAC=$(SUPPORT)/ipac-2-15
Ø
SNCSEQ=$(SUPPORT)/seq-2-2-5
Actually asyn configure/RELEASE has explanatory comments before each of those lines:
# IPAC is only necessary if support for Greensprings IP488 is required
# IPAC release V2-7 or later is required.
IPAC=$(SUPPORT)/ipac-2-15
# SEQ is required for testIPServer
SNCSEQ=$(SUPPORT)/seq-2-2-5
## For sCalcout support in asynOctet - applications include asynCalc.dbd
#CALC=$(SUPPORT)/calc-3-7-3
# If CALC was built with SSCAN support then SSCAN must be defined for testEpicsApp
#SSCAN=$(SUPPORT)/sscan-2-11-3
# EPICS_BASE 3.14.6 or later is required
EPICS_BASE=/corvette/usr/local/epics-devel/base-7.0.4
I believe you can achieve what you want without editing RELEASE by putting these lines in RELEASE.local
SUPPORT=
IPAC=
SNCSEQ=
I think that should work because RELEASE.local is read after RELEASE, and so you will replace those 3 definitions. I have not tested it, so please try it.
Mark
From: Hu, Yong <yhu at bnl.gov>
Sent: Wednesday, April 21, 2021 9:09 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: asyn: No rule to make target 'ipSNCServer.o'; Does configure/RELEASE have multiple pointers to ...
Thanks Mark!
Yes, I have the “snc” executable installed:
ls -lth /usr/lib/epics/bin/linux-x86_64/snc*
-r-xr-xr-x. 1 root root 18K Sep 3 2020 /usr/lib/epics/bin/linux-x86_64/sncExEntry
-r-xr-xr-x. 1 root root 18K Sep 3 2020 /usr/lib/epics/bin/linux-x86_64/sncExOpt
-r-xr-xr-x. 1 root root 135K Sep 3 2020 /usr/lib/epics/bin/linux-x86_64/snc
-r-xr-xr-x. 1 root root 18K Sep 3 2020 /usr/lib/epics/bin/linux-x86_64/sncExample
The problem is actually related to BUILD_RULES as Andrew pointed out in another email.
SNCSEQ=/usr/lib/epics
ASYN=/home/yhu/epics/asyn-4-41
EPICS_BASE=/usr/lib/epics
Yes, I recall that I had this kind of problem a few years ago when I mixed my personal built newer version of asyn with the old version of asyn provided by Debian packages.
Let me further explain why I went to this trouble: I was trying to build the latest asyn (cloned from github) on Red Hat 8. As I said
here, I do not want to make any changes on configure/RELEASE (otherwise ‘git status’ will show “modified: configure/RELEASE” and I probably will get in trouble when I do something like “git pull”
in future) so that I created configure/RELEASE.local which is very simple (only one line), EPICS_BASE=/usr/lib/epics, because I think “asyn” should only depend on the EPICS base.
Initially, I thought RELEASE.local will replace RELEASE completely, meaning the EPICS build system will only use variables defined in RELEASE.local and will completely ignore all variables defined in RELEASE.
It turns out my thought is wrong. RELEASE.local seems to be an addition to RELEASE: RELEASE.local only overwrite those variables defined in RELEASE (and create new variables, which is a rare thing for users to do); if a variable is defined in RELEASE but not
in RELEASE.local, the EPICS build system (maybe it is the GNUMake system itself) will still use that variable.
“I do have SNCSEQ defined in asyn/configure/RELEASE” in my previous email actually means “I do have SNCSEQ defined in asyn/configure/RELEASE.local”.
So, my questions: do we really need the following 3 lines in asyn/configure/RELEASE? Maybe they are there just because of historical reasons? Should those be commented out by default just as “CALC” and “SSCAN”?
A simple search of “ipSNCServer.o” on Tech-Talk shows quite a few people have repeated the same problem.
SUPPORT=/corvette/home/epics/devel
IPAC=$(SUPPORT)/ipac-2-15
SNCSEQ=$(SUPPORT)/seq-2-2-5
Thanks again for your insights!
Yong
Hi Yong,
Ø
Just to be clear, the module “seq” has been installed on my server:
Ø
$ ls -lht /usr/lib/epics/lib/linux-x86_64/libseq*
The error you are getting is what will happen if it cannot find the ”snc” executable. Does that exist in /usr/lib/epics/bin/linux-x86_64?
Ø
This is the historical tradition at NSLS-2: we install all EPICS stuff (base, support modules) in a flat directory “/usr/lib/epics”.
Ø
$ ls /usr/lib/epics/
Ø
bin cfg configure db dbd include lib startup templates
It seems to me that this works fine as long as you are using all modules from /usr/lib/epics.
But now you want to use a different version of asyn from the one that is in /usr/lib/epics. That can lead to problems.
If, for example, you have an application configure/RELEASE file that looks like this:
SNCSEQ=/usr/lib/epics
ASYN=/home/yhu/epics/asyn-4-41
EPICS_BASE=/usr/lib/epics
It will not work correctly, because the search path for include and library files will first be /usr/lib/epics, then /home/yhu/epics/asyn-4-41, and then /usr/lib/epics again
(maybe, I don’t know if this is optimized out). The problem is that if your application is using asyn, then it will not find the correct asyn files in /home/yhu/epics/asyn-4-41, it will find the old asyn files in /usr/lib/epics because that is searched first.
It does not look for asyn files in ASYN, it looks for asyn files in the complete search path, including ASYN but also including everything else defined in configure/RELEASE.
I think it can be made to work correctly if you always put the new modules (the ones not in /usr/lib/epics) at the beginning of your configure/RELEASE file, before any modules
in /usr/lib/epics. But then you may need to change the order of entries in distributed configure/RELEASE files in other modules.
Ø
The building rules in base-R7.0.4.1 must have changed.
Ø
I guess the rules ignore “SNCSEQ” when SNCSEQ has the same path as EPICS_BASE.
Ø
If my guess is right, it explains why I still get the error “No rule to make target 'ipSNCServer.o'” even after I have SNCSEQ defined.
I don’t think that can be the problem. The only thing that defining SNCSEQ and EPICS_BASE does is to add them to the path for searching for dbd files, include files, library
files, etc. /usr/lib/epics only needs to be in that path once, so the problem cannot be that it is ignoring SNCSEQ, because EPICS_BASE alone should be sufficient.
Mark