1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: asyn: No rule to make target 'ipSNCServer.o'; Does configure/RELEASE have multiple pointers to ... |
From: | "Hu, Yong via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu> |
Cc: | EPICS Tech-Talk <tech-talk at aps.anl.gov> |
Date: | Wed, 21 Apr 2021 14:08:33 +0000 |
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 From: Mark Rivers <rivers at cars.uchicago.edu> Hi Yong,
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?
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.
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 |