Hi Andrew,
The epics version is 3.14.12.2, if that is important to know.
I made these modifications to the Makefile in the src directory of the
application as you suggested:
-------------------------------------------------------------------------------------------------------------------------------------
TOP=../..
include $(TOP)/configure/CONFIG
#----------------------------------------
# ADD MACRO DEFINITIONS AFTER THIS LINE
#=============================
#==================================================
# build a support library
LIBRARY_IOC_RTEMS += cfMemMapSupport
# xxxRecord.h will be created from xxxRecord.dbd
DBDINC_RTEMS += nslsdetRecord
# install devXxxSoft.dbd into <top>/dbd
#DBD += cfMemMapSupport.dbd
# The following are compiled and added to the Support library
cfMemMapSupport_SRCS_RTEMS += devCfMemMap_bi_bo.c
cfMemMapSupport_SRCS_RTEMS += devCfSPI.c
cfMemMapSupport_SRCS_RTEMS += nslsdetRecord.c
cfMemMapSupport_SRCS_RTEMS += devNslsdet.c
cfMemMapSupport_LIBS_RTEMS += $(EPICS_BASE_IOC_LIBS)
#=============================
# build an ioc application
PROD_IOC_RTEMS = cfMemMap
# <name>.dbd will be created from <name>Include.dbd
DBD_RTEMS += cfMemMap.dbd
# <name>_registerRecordDeviceDriver.cpp will be created from <name>.dbd
cfMemMap_SRCS_RTEMS += cfMemMap_registerRecordDeviceDriver.cpp
cfMemMap_SRCS_RTEMS += cfMemMapMain.cpp
# Add locally compiled object code
#cfMemMap_SRCS += dbSubExample.c
cfMemMap_LIBS_RTEMS += cfMemMapSupport
# NOTES:
# 1)It is not possible to build sncExample both as a component of
cfMemMap
# and standalone. You must choose only one.
# 2)To build sncExample SNCSEQ must be defined in
<top>/configure/RELEASE
# The following builds sncExample as a component of cfMemMap
#cfMemMap_SRCS += sncExample.stt
#cfMemMap_LIBS += seq pv
cfMemMap_LIBS_RTEMS += $(EPICS_BASE_IOC_LIBS)
# The following builds sncExample as a standalone application
#PROD_HOST += sncExample
#sncExample_SNCFLAGS += +m
#sncExample_SRCS += sncExample.stt
#sncExample_LIBS += seq pv
#sncExample_LIBS += $(EPICS_BASE_HOST_LIBS)
#===========================
include $(TOP)/configure/RULES
#----------------------------------------
# ADD RULES AFTER THIS LINE
#define _RamSize=0xff0000
-----------------------------------------------------------------------------------------------------------------------------
and then make clean uninstall, then:
peter@peter-Latitude-E4200:~/IOCs/det_640$ make
make -C ./configure install
make[1]: Entering directory `/home/peter/IOCs/det_640/configure'
perl /usr/local/epics/base/bin/linux-x86_64/makeMakefile.pl
O.RTEMS-uC5272 ../..
mkdir O.Common
make[1]: *** No rule to make target `install.linux-x86_64', needed by
`install.RTEMS-uC5272'. Stop.
make[1]: Leaving directory `/home/peter/IOCs/det_640/configure'
make: *** [configure.install] Error 2
so it seems to fail at the very first step, before even looking at the
src directory. GIven my history with this stuff it is almost certainly a
dumb mistake :)
THanks,
Pete.
On 04/01/2014 11:32 AM, Andrew Johnson wrote:
Hi Peter,
On 04/01/2014 10:04 AM, D Peter Siddons wrote:
I had done that to verify the install, and had built a custom
application, host-based, quite successfully. THe problem is with a
cross-build, and that fails in the top-level makefile with the error I
sent. I don't know why a cross-build of an application should need to
invoke a host-build (as indicated by the error message). THe top level
Makefile is the standard one:
Cross-builds now depend on the host build; this is fixed in stone. The
dependency is necessary for parallel make (-j option) runs to succeed,
since there could be a host tool (such as a Perl script) being built
and/or installed that gets run during the cross-build process (say the
tool creates .db files).
Thus if you used to run something like 'make <cross-target>' because
your Makefiles don't work when compiling for the host OS, you now have
to fix those Makefiles and run 'make' instead. That's not usually very
hard, you just change the target variables to ones that only build for
the OSCLASS that you're interested in. For example, instead of
LIBRARY = myRtemsDevice
you use
LIBRARY_RTEMS = myRtemsDevice
or
PROD_IOC = test
becomes
PROD_IOC_RTEMS = test
None of the other variables that list the sources or link libraries need
to change, only the ones that tell GnuMake what to build. The Build
chapter of the Application Developers Guide details all the variables
you can use that have an _<osclass> suffix.
If you have code that can only be compiled for a specific target, say it
compiles for RTEMS-uC5282 but fails for RTEMS-mv3100 (both of which are
in the same RTEMS OSCLASS) I can show you how to do that.
Does this explain the problem?
- Andrew
--
D. Peter Siddons
Detector Development Group Leader
Bldg. 535B
Photon Sciences Directorate,
Brookhaven National Laboratory
Upton, NY 11973
email: [email protected]
Phone: (631) 344-2738
- Replies:
- Re: build question Andrew Johnson
- References:
- build question D Peter Siddons
- Re: build question Andrew Johnson
- Re: build question D Peter Siddons
- Re: build question Andrew Johnson
- Navigate by Date:
- Prev:
Re: build question Andrew Johnson
- Next:
Re: build question Andrew Johnson
- 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
- Navigate by Thread:
- Prev:
Re: build question Andrew Johnson
- Next:
Re: build question Andrew Johnson
- 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
|