C++ errors building base using cygwin1.7

Bug #595154 reported by Janet B. Anderson on 2010-06-16
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

The error messages in the ca directory are listed in Pete's email below.

I get another message in ca also:
casw.o:casw.cpp:(.rdata$_ZTI15bheFreeStoreMgr[typeinfo for bheFreeStoreMgr]+0x8): undefined reference to
`typeinfo for bheMemoryManager'

 and I get more messages of the same type in libCom/test, cas and excas. See attached file.

-------- Original Message --------


building base on cygwin1.7


Fri, 28 May 2010 17:33:44 -0500


Pete R. Jemian <email address hidden>


<email address hidden>


Advanced Photon Source


EPICS <email address hidden>

Anyone have experience yet with building EPICS base on cygwin 1.7? My

C++ is not good enough to resolve this problem.

EPICS_HOST_ARCH = cygwin-x86

situation: building EPICS base 3.14.11

host: cygwin 1.7 on Windows 7 Ultimate 64-bit OS

error: undefined reference to `typeinfo for epicsTimerNotify'

fails: Win7-64bit / cygwin1.7

succeeds: Win7-64bit / cygwin1.5

succeeds: Win7-32bit / cygwin1.5

not tested yet: Win7-32bit / cygwin1.7

The build fails

-----------------% clip here %-----------------

make[3]: Entering directory




     -O3 -Wall -m32 -D_DLL -I. -I../O.Common -I. -I..

-I../../../include/os/cygwin32 -I../../../include


g++ -o ca.dll -shared -Wl,--out-implib,ca.lib

-Lc:/Users/Pete/Apps/epics/base-3-14-11/lib/cygwin-x86 -m32

           cac.o cacChannel.o cacChannelNotify.o cacContextNotify.o

cacReadNotify.o cacWriteNotify.o cacStateNotify.o access.o iocinf.o

convert.o test_event.o repeater.o searchTimer.o

disconnectGovernorTimer.o repeaterSubscribeTimer.o baseNMIU.o nciu.o

netiiu.o udpiiu.o tcpiiu.o noopiiu.o netReadNotifyIO.o

netWriteNotifyIO.o netSubscription.o tcpSendWatchdog.o tcpRecvWatchdog.o

bhe.o ca_client_context.o oldChannelNotify.o oldSubscription.o

getCallback.o getCopy.o putCallback.o syncgrp.o CASG.o syncGroupNotify.o

syncGroupReadNotify.o syncGroupWriteNotify.o localHostName.o

comQueRecv.o comQueSend.o comBuf.o hostNameCache.o

msgForMultiplyDefinedPV.o ca.coff -lCom -lpthread -lreadline

-lcurses -lm

Creating library file:


for searchTimer]+0x10): undefined reference to `typeinfo for



for disconnectGovernorTimer]+0x10): undefined reference to `typeinfo for



for repeaterSubscribeTimer]+0x10): undefined reference to `typeinfo for



for tcpSendWatchdog]+0x10): undefined reference to `typeinfo for



for tcpRecvWatchdog]+0x10): undefined reference to `typeinfo for


collect2: ld returned 1 exit status

make[3]: *** [ca.dll] Error 1

make[3]: Leaving directory


make[2]: *** [install.cygwin-x86] Error 2

make[2]: Leaving directory


make[1]: *** [ca.install] Error 2

make[1]: Leaving directory


make: *** [src.install] Error 2

-----------------% clip here %-----------------


Andrew Johnson (anj) wrote :

Michael Davidsaver believes this patch he developed will solve this issue. Not tried it myself though.

Changed in epics-base:
importance: Undecided → High
status: New → Confirmed
Jeff Hill (johill-lanl) wrote :

The issue also does not appear to occur in the cvs main trunk branch on launchpad. I attached the diffs which also include other changes.

Also here is my message to Michael on this topic:

Sorry about the delay, I am on call this week and ... you know how that goes no doubt. I have MINGW GCC 4.4 installed. When I am building on the cvs main trunk branch in launch-pad the build completes w/o issue with mingw, and so I was perplexed concerning why these changes are necessary. I have attached the diffs between the cvs trunk branch and the launchpad trunk because it appears that I have fixed the issue a different way. The change that fixes the issue may be not instantiating the virtual dtor - i.e. not adding this code to epicsTimer.cpp "epicsTimer::~epicsTimer () {}". So maybe, in principal, it shouldn’t be necessary to have any export decoration on a pure virtual base class. Nevertheless, there is nothing wrong with your changes - just a different fix for the same issue. At this point I don’t claim to understand which way is optimal although complete removal of epicsShareClass from pure virtual interfaces is perhaps appealing. The simplest approach that will compile on all of the windows compilers will probably be best. This particular issue will of course occur in 100 bazillion other places in base.

Is there a launchpad branch associated with this change that needs approving?

PS: I do also see many (huge numbers of) warnings like this with g++ 4.4 that I don’t claim to understand at this point.

Info: resolving _pvar_func_asSub by linking to __imp__pvar_func_asSub (auto-import)

Andrew Johnson (anj) wrote :

Note: Micheal withdrew the patch for now, a better solution is under way.

Andrew Johnson (anj) wrote :

Fixed in 3.14.12.

Changed in epics-base:
status: Confirmed → Fix Committed
Andrew Johnson (anj) on 2010-11-24
Changed in epics-base:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments