Core-talk,
Am I missing something? My first build of a VxWorks IOC using
R3.14.9-pre2 gave the following on boot:
ld < bin/vxWorks-ppc604_long/slitTest.munch
Undefined symbol: push__H1Zi_6comBufPCX01Ui_Ui (binding 1 type 0)
Undefined symbol: pop__H1ZUc_6comBufRX01_Q26comBuf9popStatus (binding 1
type 0)
Undefined symbol: push__H1Zd_6comBufPCX01Ui_Ui (binding 1 type 0)
Undefined symbol: push__H1Zf_6comBufPCX01Ui_Ui (binding 1 type 0)
Undefined symbol: push__H1Zs_6comBufPCX01Ui_Ui (binding 1 type 0)
Undefined symbol: pop__H1ZUs_6comBufRX01_Q26comBuf9popStatus (binding 1
type 0)
Undefined symbol: pop__H1ZUi_6comBufRX01_Q26comBuf9popStatus (binding 1
type 0)
ld error: Module contains undefined symbol(s) and may be unusable.
These symbols are apparently referred to by comQueRecv.cpp and
comQueSend.cpp and have demangled names of:
[npr78@pc0025 vxWorks-ppc604_long]$ nm -o --demangle libca.a | grep
"comQue.*.o: *U.*comBuf::p"
libca.a:comQueRecv.o: U comBuf::popStatus comBuf::pop<unsigned
char>(unsigned char &)
libca.a:comQueRecv.o: U comBuf::popStatus comBuf::pop<unsigned
int>(unsigned int &)
libca.a:comQueRecv.o: U comBuf::popStatus comBuf::pop<unsigned
short>(unsigned short &)
libca.a:comQueSend.o: U unsigned int comBuf::push<double>(double
const *, unsigned int)
libca.a:comQueSend.o: U unsigned int comBuf::push<float>(float
const *, unsigned int)
libca.a:comQueSend.o: U unsigned int comBuf::push<int>(int const
*, unsigned int)
libca.a:comQueSend.o: U unsigned int comBuf::push<short>(short
const *, unsigned int)
These appear to be defined in comBuf.h, but don't seem to be making it
into libca.c.
The cc version I am using is:
[npr78@pc0025 ca]$ ccppc -v
Reading specs from
/dls_sw/targetOS/vxWorks/Tornado-2.2/host/i386-Linux/bin/../lib/gcc-lib/
powerpc-wrs-vxworks/gcc-2.96/specs
gcc version gcc-2.96 (2.96+) 19990621 AltiVec
Any ideas?
Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713
- Replies:
- Re: EPICS R3.14.9 experiences Andrew Johnson
- Navigate by Date:
- Prev:
Re: yet another bug in mkmf.pl Janet Anderson
- Next:
Re: C++ Exceptions from CAC-UDP on exit Andrew Johnson
- Index:
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: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Next:
Re: EPICS R3.14.9 experiences Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|